[Oa-italia] Classics Research Network

Lun 23 Gen 2012 11:06:19 CET

Sì, credo che Andrea abbia ragione per il crawler che usa Google Scholar
nel caso degli IR.
Anche per quanto riguarda le annate dei periodici elettronici se registrate
in SFX Google Scholar usa il suo crawler.
È 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.
Anche le piattaforme degli IR dovrebbero diventare più sofisticate e
consentire scelte specifiche.
Pierfranco Minsenti

Il giorno 23 gennaio 2012 10:54, Andrea Zanni <zanni.andrea84 a gmail.com> ha
scritto:

> Scusate l'intervento forse off topic,
> ma da quel che mi risulta Google Scholar non utilizza il protocollo OAI.
> Credo utilizzino una versione customizzata del crawler normale di Google.
>
> Andrea Zanni
>
> AlmaDL
>
> Il giorno 23 gennaio 2012 10:41, Pierfranco Minsenti <
> pierfranco.minsenti a iuav.it> ha scritto:
>
> 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/
>>>
>>
>>
>>
>> _______________________________________________
>> 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/
>

-- 
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

---------------------------------------------------------------------------------
ll contenuto di questa e-mail e dei suoi eventuali allegati è rivolto
unicamente alle persone alle quali è indirizzato, e può contenere
informazioni la cui riservatezza è tutelata. Sono vietati la riproduzione
e l’uso di questa e-mail in mancanza di  autorizzazione del destinatario.
Se avete ricevuto questa e-mail per errore, vogliate cortesemente
informare immediatamente il mittente ed eliminare il messaggio dal
vostro sistema di posta. Il carattere confidenziale di questa e-mail
non viene meno a causa di questo errore.
--------------
This e-mail, together with any attachments, is intended for the named
recipient(s) only and may contain information that is privileged,
confidential or otherwise protected from disclosure.
Copying, dissemination or use of this e-mail or the information herein
by anyone other than the intended recipient is prohibited unless
expressly authorised by the sender. If you have received this e-mail
by mistake, please inform the sender as soon as possible and delete
the message and any copies of this message from your computer
system network. The confidentiality and privacy attached to this
email is not waived or destroyed by that mistake.
---------------------------------------------------------------------------------
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://liste.cineca.it/pipermail/oa-italia/attachments/20120123/775b0f2d/attachment.html>