[Oa-italia] Classics Research Network

Sab 21 Gen 2012 22:27:12 CET

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/