[Oa-italia] Classics Research Network

Sab 21 Gen 2012 20:05:23 CET

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/
>
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://liste.cineca.it/pipermail/oa-italia/attachments/20120121/72eb21e0/attachment.html>