Sì, credo che Andrea abbia ragione per il crawler che usa Google Scholar nel caso degli IR.<div>Anche per quanto riguarda le annate dei periodici elettronici se registrate in SFX Google Scholar usa il suo crawler.</div><div>
È vero però che SFX mi dà la possibilità di decidere che cosa esporre a Google Scholar dei miei periodici elettronici: possono essere tutti o una parte. SFX in base alla mia scelta produce periodicamente un file XML che conterrà i dati delle mie collezioni ma con le specifiche che ho scelto.</div>
<div>Anche le piattaforme degli IR dovrebbero diventare più sofisticate e consentire scelte specifiche.</div><div>Pierfranco Minsenti</div><div><br><br><div class="gmail_quote">Il giorno 23 gennaio 2012 10:54, Andrea Zanni <span dir="ltr"><<a href="mailto:zanni.andrea84@gmail.com">zanni.andrea84@gmail.com</a>></span> ha scritto:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Scusate l'intervento forse off topic, <br>ma da quel che mi risulta Google Scholar non utilizza il protocollo OAI.<br>
Credo utilizzino una versione customizzata del crawler normale di Google.<br><br>Andrea Zanni<br><br>
AlmaDL<br><br><div class="gmail_quote">Il giorno 23 gennaio 2012 10:41, Pierfranco Minsenti <span dir="ltr"><<a href="mailto:pierfranco.minsenti@iuav.it" target="_blank">pierfranco.minsenti@iuav.it</a>></span> ha scritto:<div>
<div class="h5"><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Cara Alessandra,<div><br></div><div>sono d'accordo con tutto quello che scrivi e in particolare con l'esigenza di ripensare i formati di metadati degli IR.</div><div>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.</div>
<div>Vedo almeno 2 obiettivi concreti su cui bisognerebbe lavorare in comune:</div><div>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</div>
<div>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: <a href="http://www.agls.gov.au/" target="_blank">http://www.agls.gov.au/</a></div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>Pierfranco Minsenti</div><div><br></div><div><div>-- <br><div>Pierfranco Minsenti</div><div><br></div><div>Università Iuav di Venezia</div></div><div><div>Area infrastrutture</div><div>Divisione servizi ICT</div>
<div>Ex-Cotonificio Veneziano</div></div><div><div>Dorsoduro, 2196 | 30123 Venezia</div><div>Tel. <a href="tel:%2B39%20041%20257%201015" value="+390412571015" target="_blank">+39 041 257 1015</a></div><div><br>
</div></div><div>E-mail: <a href="mailto:pierfranco.minsenti@iuav.it" target="_blank">pierfranco.minsenti@iuav.it</a> | skype: pierfranco.minsenti</div>
<div><br></div></div><div><br></div><div><br><br><div class="gmail_quote">Il giorno 21 gennaio 2012 22:27, <span dir="ltr"><<a href="mailto:abianchi@unibg.it" target="_blank">abianchi@unibg.it</a>></span> ha scritto:<div>
<div><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Gentile PierFranco,<br>
davvero il dublin core come namespace unico è veramente troppo stretto per<br>
gli IR, specialmente in casi come il nostro, in cui l'IR serve sia come db<br>
per la valutazione della ricerca, che come piattaforma "editoriale" (tesi<br>
dottorato etc.), che come repository della didattica.<br>
Giusto ieri ho saputo che, per "rincorrere" la nuova scheda del Sito<br>
docente del ministero dovrò aggiungere altri 3 dc.description: ne abbiamo<br>
già una profusione.<br>
<br>
I "service providers" con cui già ci interfacciamo (bncf, openAire, etc.)<br>
chiedono campi riservati o semantiche specifiche per alcuni campi. Vero<br>
che molto può essere fatto a livello di mappatura (magari con più di una<br>
baseurl?), ma non possiamo continuare a moltiplicare i dc.description e le<br>
qualificazioni casalinghe all'infinito. Spesso poi non soddisfano il<br>
criterio del dumb-down per cui quando poi si dequalifica in uscita...<br>
<br>
Bisognerebbe capire se il DCMI task group per i repository (ma esiste?)<br>
sta lavorando su qualche AP che tenga conto di tutti questi aspetti.<br>
Personalmente anch'io propendo per un'estensione MODS.<br>
<br>
L'altra via è quella, appunto, dei set: separare bene le collezioni in<br>
DSpace e poi scegliere di volta in volta quali esporre e a chi. La mia<br>
preoccupazione più grande in questo momento è Scholar: ora che ho nell'IR<br>
anche record bibliografici senza full text (sempre per la faccenda della<br>
valutazione della ricerca)... per il senso di colpa ho scritto una mail di<br>
autodenuncia a Scholar! Vorrei riuscire a indicizzarci solo le collezioni<br>
editoriali, che hanno il full text, ma come fare?<br>
<br>
Riguardo al rapporto con i repository disciplinari, di qualisasi età e<br>
fattezza, più vado avanti e più mi rendo conto che i nostri utenti<br>
(ricercatori) ci tengono moltissimo, del resto obiettivamente hanno un<br>
notevole valore aggiunto. ArXiv, RePEc e SSRN che al momento è il più<br>
desiderato (almeno dal riscontro che ho io).<br>
<br>
Come staff del repository ci siamo sobbarcati di "esporre manualmente"<br>
(nel senso che bisogna aggiornare record-per-record dei file txt messi su<br>
un ns. server) alcune collezioni dell'IR a RePEc, un lavoraccio!<br>
SSRN funziona a "inclusion", come dice Antonella, e non a<br>
"indexing/harvesting": il gioco è ancora più duro...<br>
Forse se riusciamo a fare dell'IR (anche) una vera piattaforma editoriale<br>
(oltre che per la disseminazione di copie aggiuntive di cose pubblicate<br>
altrove), sposando il green al gold OA secondo il modello overlay. Io ci<br>
credo, ma forse invece è come voler fare il risotto con la macchinetta del<br>
caffè?<br>
<br>
ale.b<br>
<div><div><br>
> L'ipotesi/domanda di Alessandra Bianchi sulle funzioni di SSRN<br>
> (indicizzazione dei records prodotti da repository esterni) è<br>
interessante<br>
> e rivela quella che rimane tutt'ora una strada ancora poco sfruttata nel<br>
mondo OAI: quella dei service providers che svolgano la funzione di<br>
aggregatori di metadati che harvestizzano metadati prodotti da archivi<br>
elettronici OA esterni e che una volta creato un indice unico tramite<br>
aggregazione offrano servizi: a cominciare dai servizi di ricerca. Il<br>
modello specializzato basato su due funzioni distinti, data providers /<br>
> service providers, previsto fin dalla nascita del protocollo OAI-PMH, di<br>
fatto non ha ancora visto la nascita di molti servizi da parte di<br>
service<br>
> providers che facciano da aggregatori di tipo disciplinare.<br>
> Hanno avuto più fortuna i grandi service providers come OAIster, non<br>
basati<br>
> su specializzazioni disciplinari. E anche Europeana è basata sulla<br>
filosofia del service provider OAI.<br>
> A questo punto però proviamo un attimo a riflettere: se esistessero<br>
service<br>
> providers che funzionano da aggregatori su base disciplinare, saremmo<br>
pronti, potremmo veramente approfittarne?<br>
> A me pare di no perché ho l'impressione che non abbiamo ancora<br>
> approfondito<br>
> a sufficienza tutte le criticità insite nella condivisione di records<br>
tramite protocollo OAI-PMH usato dai repository OA per esporre i<br>
metadati<br>
> e<br>
> dai service providers per harvestizzare<br>
> Ci siamo preoccupati di adottare piattaforme per la creazione di data<br>
providers OA come Eprints e DSpace, ma forse non ci siamo preoccupati a<br>
sufficienza di farci trovare pronti per i servizi di aggregazione. Questo<br>
richiederebbe delle operazioni preventive al livello di:<br>
> 1. partizione della base dati OA seguendo le convenzioni OAI che<br>
richiedono<br>
> la creazione di gruppi chiamati set costruendoli su base disciplinare 2.<br>
scelte precise a livello del formato dati che dovrà essere reso<br>
disponibile tramite OAI-PMH.<br>
> Invece se osserviamo la situazione dei repository DSpace per quanto<br>
riguarda il formato dei metadati, scopriamo che offrono la possibilità di<br>
> personalizzare gli elementi del Dublin Core, ma questa possibilità non<br>
ha<br>
> alcun effetto automatico a livello dei metadati esposti da DSpace<br>
tramite<br>
> protocollo OAI in cui il formato di default è il Dublin Core semplice a<br>
soli 15 campi e se non interveniamo il sistema opera conversioni<br>
automatiche che possono creare ambiguità. Così tutte le estensioni che<br>
abbiamo introdotto e usiamo nella interfaccia di editing dati verranno<br>
perse una volta che i nostri dati saranno harvestizzati dato che<br>
verranno<br>
> mappate e quindi schicciate solo sui 15 elementi del Dublin Core<br>
semplice<br>
> se non abbiamo lavorato anche sul modulo OAI di DSpace e creato una<br>
conversione automatica sensata.<br>
> Non ne sono sicuro, ma apparentemente sembra che tutte le installazioni<br>
di<br>
> DSpace italiane siano così: cioè a livello del modulo OAI hanno i<br>
metadati<br>
> in un solo formato: il Dublin Core semplice. Ma il protocollo OAI ha<br>
sempre<br>
> detto che quello era il formato dati minimo indispensabile, ma che se si<br>
volevano dati più ricchi bisognava adottare in più e in parallelo altri<br>
formati dati più ricchi: come per es. un profilo applicativo del Dublin<br>
Core o MODS.<br>
> Che in Italia si sia lavorato poco su questi aspetti lo si deduce anche<br>
da<br>
> un confronto a livello europeo per quanto riguarda l'elaborazione a<br>
livello<br>
> nazionale di un formato di metadati specifico per le tesi. Finora in<br>
Italia<br>
> non si è fatto un lavoro come quello fatto in Inghilterra, in Francia o<br>
in<br>
> Germania. Qui hanno elaborato il formato chiamato XMetaDiss, adottato<br>
anche<br>
> in Svizzera (nel sito della Biblioteca Nazjonale Svizzera esiste anche<br>
la<br>
> versione italiana scaricabile da<br>
> <a href="http://www.nb.admin.ch/nb_professionnel/01693/01699/01873/01894/index.html?lang=it&download=NHzLpZeg7t,lnp6I0NTU042l2Z6ln1ah2oZn4Z2qZpnO2Yuq2Z6gpJCDeHx2hGym162epYbg2c_JjKbNoKSn6A--" target="_blank">http://www.nb.admin.ch/nb_professionnel/01693/01699/01873/01894/index.html?lang=it&download=NHzLpZeg7t,lnp6I0NTU042l2Z6ln1ah2oZn4Z2qZpnO2Yuq2Z6gpJCDeHx2hGym162epYbg2c_JjKbNoKSn6A--</a><br>
)<br>
> Tutto quello che si è fatto in Italia sinora è consistito nelle<br>
raccomandazioni CRUI per il formato di metadati delle tesi di dottorato<br>
contenute nel documento del 2007 Linee guida per il deposito delle tesi di<br>
> dottorato negli archivi aperti (pag. 11). Per ragioni di<br>
interoperabilità<br>
> è<br>
> consigliata l'adozione del solo Dublin Core semplice a 15 elementi che<br>
in<br>
> effetti è il formato richiesto dal portale DART Europe. Non dico che si<br>
tratti di una scelta "sbagliata". Ma forse non copre tutte le esigenze. Per<br>
> es. ora in Italia ci si accorge che serve la data di nascita<br>
delll'autore<br>
> (lo studente) per disambiguare gli omonimi, ma il Dublin Core semplice<br>
non<br>
> prevede questo dato che invece è stato previsto dal formato<br>
> tedesco XMetaDiss. Così ora chi gestisce i metadati per le tesi di<br>
dottorato non sa dove aggiungere la data di nascita dell'autore e se in<br>
DSpace aggiunge un elemento apposito, per es. un elemento chiamato<br>
dc:DateOfBirth, la conseguenza al livello dei metadati Dublin Core del<br>
modulo OAI di quella installazione DSpace è che quell'elemento nuovo viene<br>
> mappato su dc:date con quella tipica operazione di<br>
> schiacciamento/semplificazione propria delle conversioni a Dublin Core<br>
semplice. Con il risultato che in questo modo nel modulo OAI esisteranno<br>
due elementi dc:date: quello della data intesa come data di<br>
> pubblicazione/discussione e quello della data intesa come data di<br>
nascita<br>
> dello studente creando un tipico caso di ambiguità per semplificazione<br>
eccessiva del formato dati.<br>
> La soluzione giusta sarebbe stata quella di creare un profilo DC ricco<br>
valido a livello nazionale e poi, dato che il DC semplice è richiesto da<br>
DART Europe, lavorare fin dall'inizio a livello delle regole automatiche<br>
di<br>
> conversione al formato dati del modulo OAI di DSpace per impedire<br>
conversioni automatiche che creano ambiguità.<br>
> Insomma: mi pare che anche su questo fronte il confronto con il resto<br>
d'Europa dovrebbe spronarci a capire che abbiamo molto lavoro da fare. E<br>
sarebbe molto utile confrontarsi su questo.<br>
> Pierfranco Minsenti<br>
> --<br>
> Pierfranco Minsenti<br>
> Università Iuav di Venezia<br>
> Dorsoduro, 2196 | 30123 Venezia<br>
> Tel. <a href="tel:%2B39%20041%20257%201015" value="+390412571015" target="_blank">+39 041 257 1015</a><br>
> E-mail: <a href="mailto:pminsenti@iuav.it" target="_blank">pminsenti@iuav.it</a> | skype: pierfranco.minsenti<br>
> Il giorno 21 gennaio 2012 18:26, Antonella De Robbio <<br>
> <a href="mailto:antonella.derobbio@unipd.it" target="_blank">antonella.derobbio@unipd.it</a>> ha scritto:<br>
>> 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 modello<br>
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 sulle<br>
novità in pubblicazione e accordano permessi per il deposito in 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>
>> Mi riferivo alla classifica Ranking web of world repositories, dove<br>
SSRN risulta al primo posto.<br>
>> antonella de robbio<br>
>> Il 20 gennaio 2012 14:46, Maria Cassella <<a href="mailto:maria.cassella@unito.it" target="_blank">maria.cassella@unito.it</a>> ha<br>
scritto:<br>
>> > Il 20/01/2012 13.50, Alessandra Bianchi ha scritto:<br>
>> >> Non si sa se SSRN può "indicizzare" in qualche modo le collezioni<br>
dei<br>
>> >> repository, stile RePEc?<br>
>> >> Il 20/01/2012 13:41, Maria Cassella ha scritto:<br>
>> > non vorrei sbagliarmi ma credo proprio di no l'architettura di PePEc<br>
>> e'<br>
>> > distribuita; quella di SSRN no, mi sembra abbia solo dei server<br>
>> mirror.<br>
>> > ciao<br>
>> > maria<br>
>> > _______________________________________________<br>
>> > OA-Italia mailing list<br>
>> > <a href="mailto:OA-Italia@openarchives.it" target="_blank">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>
>> 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" target="_blank">++ 39 049 8273654</a><br>
>> ++ <a href="tel:334%206960555" value="+13346960555" target="_blank">334 6960555</a><br>
>> ""Chi ha trascurato la propria educazione non sa fare uso della propria<br>
libertà". Kant<br>
>> _______________________________________________<br>
>> OA-Italia mailing list<br>
>> <a href="mailto:OA-Italia@openarchives.it" target="_blank">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>
> OA-Italia mailing list<br>
> <a href="mailto:OA-Italia@openarchives.it" target="_blank">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>Alessandra Bianchi<br>
Università degli studi di Bergamo<br>
Amministratore Aisberg - Archivio istituzionale ad accesso aperto<br>
dell'Università di Bergamo<br>
via dei Caniana, 2<br>
24127 - Bergamo<br>
tel.: <a href="tel:%2B39-035-2052548" value="+390352052548" target="_blank">+39-035-2052548</a><br>
</div>fax: <a href="tel:%2B39-035-2052569" value="+390352052569" target="_blank">+39-035-2052569</a><br>
mailto: <a href="mailto:alessandra.bianchi@unibg.it" target="_blank">alessandra.bianchi@unibg.it</a><br>
site: <a href="http://dspace-unibg.cilea.it/" target="_blank">http://dspace-unibg.cilea.it/</a><br>
<div><div><br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
OA-Italia mailing list<br>
<a href="mailto:OA-Italia@openarchives.it" target="_blank">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><br>
</div>
<br>_______________________________________________<br>
OA-Italia mailing list<br>
<a href="mailto:OA-Italia@openarchives.it" target="_blank">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></blockquote></div></div></div><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></blockquote></div><br><br clear="all"><div><br></div>-- <br><div>Pierfranco Minsenti</div><div><br></div>
<div>Università Iuav di Venezia</div><div><div>Area infrastrutture</div><div>Divisione servizi ICT</div><div>Ex-Cotonificio Veneziano</div></div><div>Dorsoduro, 2196 | 30123 Venezia</div><div>Tel. +39 041 257 1015</div><div>
<br></div><div>E-mail: <a href="mailto:pierfranco.minsenti@iuav.it" target="_blank">pierfranco.minsenti@iuav.it</a> | skype: pierfranco.minsenti</div><div><br></div><div>---------------------------------------------------------------------------------</div>
<div>ll contenuto di questa e-mail e dei suoi eventuali allegati è rivolto</div><div>unicamente alle persone alle quali è indirizzato, e può contenere</div><div>informazioni la cui riservatezza è tutelata. Sono vietati la riproduzione</div>
<div>e l’uso di questa e-mail in mancanza di autorizzazione del destinatario.</div><div>Se avete ricevuto questa e-mail per errore, vogliate cortesemente</div><div>informare immediatamente il mittente ed eliminare il messaggio dal</div>
<div>vostro sistema di posta. Il carattere confidenziale di questa e-mail</div><div>non viene meno a causa di questo errore.</div><div>--------------</div><div>This e-mail, together with any attachments, is intended for the named</div>
<div>recipient(s) only and may contain information that is privileged,</div><div>confidential or otherwise protected from disclosure. </div><div>Copying, dissemination or use of this e-mail or the information herein</div>
<div>by anyone other than the intended recipient is prohibited unless</div><div>expressly authorised by the sender. If you have received this e-mail</div><div>by mistake, please inform the sender as soon as possible and delete</div>
<div>the message and any copies of this message from your computer</div><div>system network. The confidentiality and privacy attached to this</div><div>email is not waived or destroyed by that mistake.</div><div>---------------------------------------------------------------------------------</div>
<br>
</div>