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.<div>
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.</div>
<div>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.</div><div><br></div><div>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?</div>
<div>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</div>
<div>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.</div><div>
Questo richiederebbe delle operazioni preventive al livello di:</div><div>1. partizione della base dati OA seguendo le convenzioni OAI che richiedono la creazione di gruppi chiamati set costruendoli su base disciplinare</div>
<div>2. scelte precise a livello del formato dati che dovrà essere reso disponibile tramite OAI-PMH.</div><div><br></div><div>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.</div>
<div>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.</div>
<div><br></div><div>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 <a href="http://www.nb.admin.ch/nb_professionnel/01693/01699/01873/01894/index.html?lang=it&download=NHzLpZeg7t,lnp6I0NTU042l2Z6ln1ah2oZn4Z2qZpnO2Yuq2Z6gpJCDeHx2hGym162epYbg2c_JjKbNoKSn6A--">http://www.nb.admin.ch/nb_professionnel/01693/01699/01873/01894/index.html?lang=it&download=NHzLpZeg7t,lnp6I0NTU042l2Z6ln1ah2oZn4Z2qZpnO2Yuq2Z6gpJCDeHx2hGym162epYbg2c_JjKbNoKSn6A--</a>)</div>
<div><br></div><div>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. </div>
<div>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à.</div>
<div><br></div><div>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.</div><div>
<br></div><div>Pierfranco Minsenti</div><div><br></div><div><br class="Apple-interchange-newline">-- <br><div>Pierfranco Minsenti</div><div><br></div><div>Università Iuav di Venezia</div><div>Dorsoduro, 2196 | 30123 Venezia</div>
<div>Tel. +39 041 257 1015</div><div><br></div><div>E-mail: <a href="mailto:pminsenti@iuav.it" target="_blank">pminsenti@iuav.it</a> | skype: pierfranco.minsenti</div><div><br></div></div>
<div><br></div><div><br></div><div><br><div class="gmail_quote">Il giorno 21 gennaio 2012 18:26, Antonella De Robbio <span dir="ltr"><<a href="mailto:antonella.derobbio@unipd.it">antonella.derobbio@unipd.it</a>></span> ha scritto:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Cara Alessandra,<br>
Come dice Maria, RePeC è un repository federato, una sorta di network,<br>
mentre SSRN è anch'esop un network ma di fatto è un repository su<br>
modello accentrato (come arXive ed E-LIS per capirci).<br>
Solo che SSRN contiene anche papers ad accesso chiuso che vengono<br>
venduti. E' un modello di business diverso dai tipici OA, ma comunque<br>
interessante.<br>
E' un modello ibrido in quanto lavora con partners tra i quali editori<br>
e istituzioni in programmi che coinvolgono oltre 1.800 periodici<br>
scientifici e istituzioni di ricerca che forniscono le informazioni<br>
sulle novità in pubblicazione e accordano permessi per il deposito in<br>
SSRN.<br>
Essendo un repository a sé non ne "indicizza" altri, ma nemmeno RePeC<br>
funziona così: RePeC raccoglie dai repository locali che aderiscono al<br>
network.<br>
In altri termini non è che SSRN indicizza ma è possibile aderire per<br>
essere incluso.<br>
Anche gli autori possono sottomettere i loro papers, ci sono requisiti<br>
sul sito, ma devono essere stati pubblicati.<br>
<br>
Mi riferivo alla classifica Ranking web of world repositories, dove<br>
SSRN risulta al primo posto.<br>
<br>
antonella de robbio<br>
<br>
<br>
Il 20 gennaio 2012 14:46, Maria Cassella <<a href="mailto:maria.cassella@unito.it">maria.cassella@unito.it</a>> ha scritto:<br>
<div class="HOEnZb"><div class="h5">> Il 20/01/2012 13.50, Alessandra Bianchi ha scritto:<br>
>> Non si sa se SSRN può "indicizzare" in qualche modo le collezioni dei<br>
>> repository, stile RePEc?<br>
>><br>
>> Il 20/01/2012 13:41, Maria Cassella ha scritto:<br>
> non vorrei sbagliarmi ma credo proprio di no l'architettura di PePEc e'<br>
> distribuita; quella di SSRN no, mi sembra abbia solo dei server mirror.<br>
> ciao<br>
> maria<br>
><br>
><br>
> _______________________________________________<br>
> OA-Italia mailing list<br>
> <a href="mailto:OA-Italia@openarchives.it">OA-Italia@openarchives.it</a><br>
> <a href="http://openarchives.it/mailman/listinfo/oa-italia" target="_blank">http://openarchives.it/mailman/listinfo/oa-italia</a><br>
> PLEIADI: <a href="http://www.openarchives.it/pleiadi/" target="_blank">http://www.openarchives.it/pleiadi/</a><br>
<br>
<br>
<br>
</div></div><div class="im HOEnZb">--<br>
Antonella De Robbio<br>
CAB Centro di Ateneo per le Biblioteche<br>
Università degli Studi di Padova<br>
Via Anghinoni, 3<br>
35121 PADOVA (ITALY)<br>
<a href="tel:%2B%2B%2039%20049%208273654" value="+390498273654">++ 39 049 8273654</a><br>
++ <a href="tel:334%206960555" value="+13346960555">334 6960555</a><br>
<br>
""Chi ha trascurato la propria educazione non sa fare uso della<br>
propria libertà". Kant<br>
<br>
</div><div class="HOEnZb"><div class="h5">_______________________________________________<br>
OA-Italia mailing list<br>
<a href="mailto:OA-Italia@openarchives.it">OA-Italia@openarchives.it</a><br>
<a href="http://openarchives.it/mailman/listinfo/oa-italia" target="_blank">http://openarchives.it/mailman/listinfo/oa-italia</a><br>
PLEIADI: <a href="http://www.openarchives.it/pleiadi/" target="_blank">http://www.openarchives.it/pleiadi/</a><br>
</div></div></blockquote></div></div><div><br></div><br>