[Oa-italia] Classics Research Network

Pierfranco Minsenti pierfranco.minsenti a iuav.it
Lun 23 Gen 2012 10:41:56 CET


Cara Alessandra,

sono d'accordo con tutto quello che scrivi e in particolare con l'esigenza
di ripensare i formati di metadati degli IR.
Credo che un nostro limite (ma mi piacerebbe molto scoprire se in Italia
qualcuno l'ha superato) è il fatto di non lavorare sulla interfaccia
OAI-PMH per migliorarla, con il risultato che questo aspetto del lavoro da
fare viene lasciato così come lo troviamo nel DSpace originario.
Vedo almeno 2 obiettivi concreti su cui bisognerebbe lavorare in comune:
1) chiedere (a CILEA?) di creare per DSpace un export OAI-PMH con un
formato MODS. D'altronde l'OAI-PMH è stato creato fin dall'inizio con
l'idea che dovesse  supportare diversi formati dati in parallelo: con il DC
semplice solo come requisito minimo indispensabile, che non vuole dire
sufficiente se lo si individua invece come un problema a causa del
meccanismo del dumb-down. In alternativa: lavorare su export DC qualificati
personalizzabili dall'istituzione
2) creare dei profili applicativi del Dublin Core (se rimane quello il
formato dati degli IR) specifici. All'estero hanno già creato profili
applicativi del DC molto specifici per poter rispondere a esigenze
differenziate. Per es. in Australia per descrivere le loro pubblicazioni
governative: AGLS: un profilo molto ben documentato, con tonnellate di
pagine, fatto davvero bene e del tutto interoperabile con DC:
http://www.agls.gov.au/

Io penso che faremo grandi passi avanti se prendessimo ad esempio lavori di
quel livello: così accurati, chiari, ben documentati, capaci di trovare un
buon equilibrio tra standard internazionali da osservare e esigenze locali
da supportare e valorizzare adeguatamente.

Per la questione DSpace / Google Scholar e la questione dei records senza
full text: anche in questo caso io credo che si potrebbe far creare un set
specifico che raggruppi tutti i records con il full text allegato.  Il
punto quindi è arrivare a poter adattare l'interfaccia OAI e farle fare
quello che ha senso che faccia per la nostra istituzione e i servizi di
export che vogliamo attivare.

Pierfranco Minsenti

-- 
Pierfranco Minsenti

Università Iuav di Venezia
Area infrastrutture
Divisione servizi ICT
Ex-Cotonificio Veneziano
Dorsoduro, 2196 | 30123 Venezia
Tel. +39 041 257 1015

E-mail: pierfranco.minsenti a iuav.it  |  skype: pierfranco.minsenti




Il giorno 21 gennaio 2012 22:27, <abianchi a unibg.it> ha scritto:

> Gentile PierFranco,
> davvero il dublin core come namespace unico è veramente troppo stretto per
> gli IR, specialmente in casi come il nostro, in cui l'IR serve sia come db
> per la valutazione della ricerca, che come piattaforma "editoriale" (tesi
> dottorato etc.), che come repository della didattica.
> Giusto ieri ho saputo che, per "rincorrere" la nuova scheda del Sito
> docente del ministero dovrò aggiungere altri 3 dc.description: ne abbiamo
> già una profusione.
>
> I "service providers" con cui già ci interfacciamo (bncf, openAire, etc.)
> chiedono campi riservati o semantiche specifiche per alcuni campi. Vero
> che molto può essere fatto a livello di mappatura (magari con più di una
> baseurl?), ma non possiamo continuare a moltiplicare i dc.description e le
> qualificazioni casalinghe all'infinito. Spesso poi non soddisfano il
> criterio del dumb-down per cui quando poi si dequalifica in uscita...
>
> Bisognerebbe capire se il DCMI task group per i repository (ma esiste?)
> sta lavorando su qualche AP che tenga conto di tutti questi aspetti.
> Personalmente anch'io propendo per un'estensione MODS.
>
> L'altra via è quella, appunto, dei set: separare bene le collezioni in
> DSpace e poi scegliere di volta in volta quali esporre e a chi. La mia
> preoccupazione più grande in questo momento è Scholar: ora che ho nell'IR
> anche record bibliografici senza full text (sempre per la faccenda della
> valutazione della ricerca)... per il senso di colpa ho scritto una mail di
> autodenuncia a Scholar! Vorrei riuscire a indicizzarci solo le collezioni
> editoriali, che hanno il full text, ma come fare?
>
> Riguardo al rapporto con i repository disciplinari, di qualisasi età e
> fattezza, più vado avanti e più mi rendo conto che i nostri utenti
> (ricercatori) ci tengono moltissimo, del resto obiettivamente hanno un
> notevole valore aggiunto. ArXiv, RePEc e SSRN che al momento è il più
> desiderato (almeno dal riscontro che ho io).
>
> Come staff del repository ci siamo sobbarcati di "esporre manualmente"
> (nel senso che bisogna aggiornare record-per-record dei file txt messi su
> un ns. server) alcune collezioni dell'IR a RePEc, un lavoraccio!
> SSRN funziona a "inclusion", come dice Antonella, e non a
> "indexing/harvesting": il gioco è ancora più duro...
> Forse se riusciamo a fare dell'IR (anche) una vera piattaforma editoriale
> (oltre che per la disseminazione di copie aggiuntive di cose pubblicate
> altrove), sposando il green al gold OA secondo il modello overlay. Io ci
> credo, ma forse invece è come voler fare il risotto con la macchinetta del
> caffè?
>
> ale.b
>
> > L'ipotesi/domanda di Alessandra Bianchi sulle funzioni di SSRN
> > (indicizzazione dei records prodotti da repository esterni) è
> interessante
> > e rivela quella che rimane tutt'ora una strada ancora poco sfruttata nel
> mondo OAI: quella dei service providers che svolgano la funzione di
> aggregatori di metadati che harvestizzano metadati prodotti da archivi
> elettronici OA esterni e che una volta creato un indice unico tramite
> aggregazione offrano servizi: a cominciare dai servizi di ricerca. Il
> modello specializzato basato su due funzioni distinti, data providers /
> > service providers, previsto fin dalla nascita del protocollo OAI-PMH, di
> fatto non ha ancora visto la nascita di molti servizi da parte di
> service
> > providers che facciano da aggregatori di tipo disciplinare.
> > Hanno avuto più fortuna i grandi service providers come OAIster, non
> basati
> > su specializzazioni disciplinari. E anche Europeana è basata sulla
> filosofia del service provider OAI.
> > A questo punto però proviamo un attimo a riflettere: se esistessero
> service
> > providers che funzionano da aggregatori su base disciplinare, saremmo
> pronti, potremmo veramente approfittarne?
> > A me pare di no perché ho l'impressione che non abbiamo ancora
> > approfondito
> > a sufficienza tutte le criticità insite nella condivisione di records
> tramite protocollo OAI-PMH usato dai repository OA per esporre i
> metadati
> > e
> > dai service providers per harvestizzare
> > Ci siamo preoccupati di adottare piattaforme per la creazione di data
> providers OA come Eprints e DSpace, ma forse non ci siamo preoccupati a
> sufficienza di farci trovare pronti per i servizi di aggregazione. Questo
> richiederebbe delle operazioni preventive al livello di:
> > 1. partizione della base dati OA seguendo le convenzioni OAI che
> richiedono
> > la creazione di gruppi chiamati set costruendoli su base disciplinare 2.
> scelte precise a livello del formato dati che dovrà essere reso
> disponibile tramite OAI-PMH.
> > Invece se osserviamo la situazione dei repository DSpace per quanto
> riguarda il formato dei metadati, scopriamo che offrono la possibilità di
> > personalizzare gli elementi del Dublin Core, ma questa possibilità non
> ha
> > alcun effetto automatico a livello dei metadati esposti da DSpace
> tramite
> > protocollo OAI in cui il formato di default è il Dublin Core semplice a
> soli 15 campi e se non interveniamo il sistema opera conversioni
> automatiche che possono creare ambiguità. Così tutte le estensioni che
> abbiamo introdotto e usiamo nella interfaccia di editing dati verranno
> perse una volta che i nostri dati saranno harvestizzati dato che
> verranno
> > mappate e quindi schicciate solo sui 15 elementi del Dublin Core
> semplice
> > se non abbiamo lavorato anche sul modulo OAI di DSpace e creato una
> conversione automatica sensata.
> > Non ne sono sicuro, ma apparentemente sembra che tutte le installazioni
> di
> > DSpace italiane siano così: cioè a livello del modulo OAI hanno i
> metadati
> > in un solo formato: il Dublin Core semplice. Ma il protocollo OAI ha
> sempre
> > detto che quello era il formato dati minimo indispensabile, ma che se si
> volevano dati più ricchi bisognava adottare in più e in parallelo altri
> formati dati più ricchi: come per es. un profilo applicativo del Dublin
> Core o MODS.
> > Che in Italia si sia lavorato poco su questi aspetti lo si deduce anche
> da
> > un confronto a livello europeo per quanto riguarda l'elaborazione a
> livello
> > nazionale di un formato di metadati specifico per le tesi. Finora in
> Italia
> > non si è fatto un lavoro come quello fatto in Inghilterra, in Francia o
> in
> > Germania. Qui hanno elaborato il formato chiamato XMetaDiss, adottato
> anche
> > in Svizzera (nel sito della Biblioteca Nazjonale Svizzera esiste anche
> la
> > versione italiana scaricabile da
> >
> http://www.nb.admin.ch/nb_professionnel/01693/01699/01873/01894/index.html?lang=it&download=NHzLpZeg7t,lnp6I0NTU042l2Z6ln1ah2oZn4Z2qZpnO2Yuq2Z6gpJCDeHx2hGym162epYbg2c_JjKbNoKSn6A--
> )
> > Tutto quello che si è fatto in Italia sinora è consistito nelle
> raccomandazioni CRUI per il formato di metadati delle tesi di dottorato
> contenute nel documento del 2007 Linee guida per il deposito delle tesi di
> > dottorato negli archivi aperti (pag. 11). Per ragioni di
> interoperabilità
> > è
> > consigliata l'adozione del solo Dublin Core semplice a 15 elementi che
> in
> > effetti è il formato richiesto dal portale DART Europe. Non dico che si
> tratti di una scelta "sbagliata". Ma forse non copre tutte le esigenze. Per
> > es. ora in Italia ci si accorge che serve la data di nascita
> delll'autore
> > (lo studente) per disambiguare gli omonimi, ma il Dublin Core semplice
> non
> > prevede questo dato che invece è stato previsto dal formato
> > tedesco  XMetaDiss. Così ora chi gestisce i metadati per le tesi di
> dottorato non sa dove aggiungere la data di nascita dell'autore e se in
> DSpace aggiunge un elemento apposito, per es. un elemento chiamato
> dc:DateOfBirth, la conseguenza al livello dei metadati Dublin Core del
> modulo OAI di quella installazione DSpace è che quell'elemento nuovo viene
> > mappato su dc:date con quella tipica operazione di
> > schiacciamento/semplificazione propria delle conversioni a Dublin Core
> semplice. Con il risultato che in questo modo nel modulo OAI esisteranno
> due elementi dc:date: quello della data intesa come data di
> > pubblicazione/discussione e quello della data intesa come data di
> nascita
> > dello studente creando un tipico caso di ambiguità per semplificazione
> eccessiva del formato dati.
> > La soluzione giusta sarebbe stata quella di creare un profilo DC ricco
> valido a livello nazionale e poi, dato che il DC semplice è richiesto da
> DART Europe, lavorare fin dall'inizio a livello delle regole automatiche
> di
> > conversione al formato dati del modulo OAI di DSpace per impedire
> conversioni automatiche che creano ambiguità.
> > Insomma: mi pare che anche su questo fronte il confronto con il resto
> d'Europa dovrebbe spronarci a capire che abbiamo molto lavoro da fare. E
> sarebbe molto utile confrontarsi su questo.
> > Pierfranco Minsenti
> > --
> > Pierfranco Minsenti
> > Università Iuav di Venezia
> > Dorsoduro, 2196 | 30123 Venezia
> > Tel. +39 041 257 1015
> > E-mail: pminsenti a iuav.it  |  skype: pierfranco.minsenti
> > Il giorno 21 gennaio 2012 18:26, Antonella De Robbio <
> > antonella.derobbio a unipd.it> ha scritto:
> >> Cara Alessandra,
> >> Come dice Maria, RePeC è un repository federato, una sorta di network,
> mentre SSRN è anch'esop un network ma di fatto è un repository su modello
> accentrato (come arXive ed E-LIS per capirci).
> >> Solo che SSRN contiene anche papers ad accesso chiuso che vengono
> venduti. E' un modello di business diverso dai tipici OA, ma comunque
> interessante.
> >> E' un modello ibrido in quanto lavora con partners tra i quali editori
> e istituzioni in programmi che coinvolgono oltre 1.800 periodici
> scientifici e istituzioni di ricerca che forniscono le informazioni sulle
> novità in pubblicazione e accordano permessi per il deposito in SSRN.
> >> Essendo un repository a sé non ne "indicizza" altri, ma nemmeno RePeC
> funziona così: RePeC raccoglie dai repository locali che aderiscono al
> network.
> >> In altri termini non è che SSRN indicizza ma è possibile aderire per
> essere incluso.
> >> Anche gli autori possono sottomettere i loro papers, ci sono requisiti
> sul sito, ma devono essere stati pubblicati.
> >> Mi riferivo alla classifica Ranking web of world repositories, dove
> SSRN risulta al primo posto.
> >> antonella de robbio
> >> Il 20 gennaio 2012 14:46, Maria Cassella <maria.cassella a unito.it> ha
> scritto:
> >> > Il 20/01/2012 13.50, Alessandra Bianchi ha scritto:
> >> >> Non si sa se SSRN può "indicizzare" in qualche modo le collezioni
> dei
> >> >> repository, stile RePEc?
> >> >> Il 20/01/2012 13:41, Maria Cassella ha scritto:
> >> > non vorrei sbagliarmi ma credo proprio di no l'architettura di PePEc
> >> e'
> >> > distribuita; quella di SSRN no, mi sembra abbia solo dei server
> >> mirror.
> >> > ciao
> >> > maria
> >> > _______________________________________________
> >> > OA-Italia mailing list
> >> > OA-Italia a openarchives.it
> >> > http://openarchives.it/mailman/listinfo/oa-italia
> >> > PLEIADI: http://www.openarchives.it/pleiadi/
> >> --
> >> Antonella De Robbio
> >> CAB Centro di Ateneo per le Biblioteche
> >> Università degli Studi di Padova
> >> Via Anghinoni, 3
> >> 35121 PADOVA (ITALY)
> >> ++ 39 049 8273654
> >> ++ 334 6960555
> >> ""Chi ha trascurato la propria educazione non sa fare uso della propria
> libertà". Kant
> >> _______________________________________________
> >> OA-Italia mailing list
> >> OA-Italia a openarchives.it
> >> http://openarchives.it/mailman/listinfo/oa-italia
> >> PLEIADI: http://www.openarchives.it/pleiadi/
> > _______________________________________________
> > OA-Italia mailing list
> > OA-Italia a openarchives.it
> > http://openarchives.it/mailman/listinfo/oa-italia
> > PLEIADI: http://www.openarchives.it/pleiadi/
>
>
> --
> Alessandra Bianchi
> Università degli studi di Bergamo
> Amministratore Aisberg - Archivio istituzionale ad accesso aperto
> dell'Università di Bergamo
> via dei Caniana, 2
> 24127 - Bergamo
> tel.: +39-035-2052548
> fax: +39-035-2052569
> mailto: alessandra.bianchi a unibg.it
> site: http://dspace-unibg.cilea.it/
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> OA-Italia mailing list
> OA-Italia a openarchives.it
> http://openarchives.it/mailman/listinfo/oa-italia
> PLEIADI: http://www.openarchives.it/pleiadi/
>
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://liste.cineca.it/pipermail/oa-italia/attachments/20120123/2dbc6c90/attachment.html>


Maggiori informazioni sulla lista OA-Italia