DDD

Marta, l'excel que has pujat és l'original, em sembla que en tens un altre, no? ;-)

Cristina Azorin va escriure:

Marta, l'excel que has pujat és l'original, em sembla que en tens un altre, no? ;-)

Correcte Cristina, m'he confós. Pujo ara l'arxiu bo, disculpa

Hola!

Contesto a sota de cada una de les qüestions que planteges:

Perquè hi ha una etiqueta 500 amb "Institut Català de Nanociència i Nanotecnologia (ICN2)"?

Resposta: perquè com que les càrregues quedaran barrejades a REVISARCIE amb la resta d'autoarxiu dels nostres centres de recerca, quan veiem aquesta nota 500 (que després esborrarem) el nostre equip DDD sabrà que cal afegir a la 980 el $b ICN2.

Les pàgines inicial i final poden no ser-hi, però si hi són cal que hi siguin les dues.

Resposta: en els articles que no hi ha pàgina final el núm que apareix no és el de la pàgina, sinó que és el núm. d'article. ja sabeu que moltes revistres electròniques no paginen, sinó que numeren els articles. En aquests casos, quan processem els registres, a la 773 esborrem el terme "p." i afegim el concepte "art." o "article" seguit del núm. corresponent. Com es pot arreglar el tema? és preferible que no us posem cap pàgina i ho fem manualment després?

Ara no té gaire importància però a partir d'ara és important que les adreces de drets sempre siguin https (https://www.europeana.eu/rights/rr-f/ enlloc de http://www.europeana.eu/rights/rr-f/)

Resposta: arreglat a la nova versió d'excel que pujo ara (eliminant l'anterior)

Pensava que els autors els posaries també en columnes, el 100 en una i els altres en les 700 que toquin (i dir-li al Ferran 700 1_ $a, la segona coma hauria de ser un $u), però tal com està ara, es carregaran tots els autors junts i després tindreu la feina de separar-los.

Resposta: No sé si recordes que vam comentar per telf que es posés tot a la 700 i després nosaltres agafaríem el primer autor i el passaríem a la 100. Pel que fa als $u passaria com amb la càrrega de PubMed, que les filiacions d'un mateix autor estan separades per coma i nosaltres afegim el $u i repolim. Però a la nova versió Excel que pujo afegeixo nota al Ferran on diu que on hi ha punt i coma (;) ha d'haver una nova 700 1_ $a perquè el que separa a cada autor és el punt i coma

Això seria pel Ferran, però digues si ho trobes bé, o si em deixo alguna cosa d'altres columnes:

• Columna N, 773 __ $x s'han perdut els zeros inicials i s'han de separar les vuit xifres amb un guió al mig

Resposta: em sembla perfecte, i aquesta nota que has posat l'he afegit a la nova versió de l'Excel.

Per part meva, cap cosa més. Només saber com queda el tema de la paginació (la treiem de l'Excel i la fem manual?), així com també saber com us fem arribar els PDF perquè l'arxiu quedi associat al registre...

Gràcies!

Marta, abans d'entrar a mirar-me l'Excel, tinc un dubte.

He vist que els de l'ICN2 tenen una pàgina amb les seves publicacions (http://icn2.cat/en/research/publications), i per a cadascuna d'elles hi ha l'enllaç a Scopus; si hi deixes el ratolí a sobre de cadascun dels enllaços, veuràs que a l'enllaç hi ha el DOI. Donat que tenim oberta una tasca ja oberta per aprofitar els registres de Scopus (#4614), utilitzar aquesta llista de DOIs ens permeteria aprofitar la feina de la tasca #4614 pèr carregar els registres de l'ICN2.

La pregunta és: quina relació hi ha entre els registres que ens passes amb l'Excel i els registres de la seva pàgina de publicacions? Podríem utilitzar la seva pàgina en comptes de l'Excel? La llista de DOIs d'aquesta pàgina estic del tot segur que es pot extreure automàticament, sense intervenció humana.

Si la diferència és que el PDF conté el preprint i el registre de Scopus descriu l'article publicat, entenc que això només afectarà el camp 655, però la resta es podria aprofitar quasi totalment, no?

Hola Ferran!

L'excel que jo et vaig enviar sé que l'extreuen d'Scopus. De fet, ells ja em van comentar que controlen el que publiquen els seus autors a través de cerques Scopus.

Ara bé, pel tema d'aprofitar aquesta feina per a la tasca pendent que hi ha, et vull comentar diverses coses, perquè les tinguis en compte:

1. l'ICN2 em van dir que els agradaria carregar tota la seva producció científica al DDD, això serien uns 1.000 articles aprox. Ho tenen tot controlat a través d'Excel
2. Ells tenen els registres, però no tenen els PDF, em van dir que es podrien carregar els registres al DDD i ells anirien subministrant els PDF a mida que els anessin recopilant.

Aquesta proposta, tal i com ells la plantejaven, no la podem assumir des de la BCT, per tant els vam fer aquesta contraproposta:

1. faríem càrregues no superiors a 50 registres. I cada Excel que ens proporcionessin havien d'anar acompanyats ja dels corresponents PDF. Quan acabéssim de processar els 50 de la càrrega 1, els demanaríem una altra remesa de 50 més.
2. No faríem càrregues de registres dels quals no tinguéssim ja el PDF

L'òbjectiu d'aquesta proposta:

1. no carregar el REVISARCIE de 1000 registres, això crea un coll d'ampolla brutal i satura la "bústia" de la BCT. L'experiència amb el REVISARCARAUT ja ens està demostrant que el nivell de reducció d'articles és lent (i això que amb el REVISARCARAUT processem els articles 4 biblioteques). Ens interessa anar netejant el REVISARCIE amb cada remesa (tenint en compte que, a més, a REVISARCIE s'anirà carregant paral·lelament amb el que van autoparxivant amb normalitat els altres centres i investigadors).
2. Amb la càrrega de cop de tots els registres ICN2, el coll d'ampolla es crea per dues bandes:

• càrrega d'un núm. de registres immenjable per part d'una sola biblioteca
• no podrem validar els registres fins que ells no aconsegueixin els PDF i ens els enviïn.

Per tant, amb això vull dir que el fet d'aprofitar la seva pàgina amb DOI / Scopus no em sembla malament sempre que es vagin carregant aquests articles de 50 en 50, a mida que ells disposin de PDF. Ara tenim aquests 10 de prova, però ja em diuen que tenen preparada una altra remesa... diga'm si es pot fer el que comentes però amb les "condicions" que marquem des de la BCT... Per exemple, amb la lllista de 10 articles que hi ha en aquesta tasca, fas la descàrrega automàtica específica d'aquests 10. És a dir, anar carregant de manera automàtica només el llistat dels articles que ells ens vagin enviant (de 50 en 50). Suposo que això implica que ells només ens hauríen de donar la llista de DOI i els PDF, i amb això ja pots anar a Scopus fer la càrrega.

Per cert, ells estan a l'espera d'enviar-me una altra remesa, volen que la col·lecció d'articles del seu portalbox vagi creixent ja.... és possible fer les proves de càrrega tal i com et comento (petites càrregues) però amb resultats visibles ja? (que apareguin ja aquests 10 i la següent remesa quan me l'enviïn) Ho dic perquè no sé si aquesta prova amb Scopus que proposes donaria resultats ràpids o si s'ha de mirar i valorar i provar i reprovar abans de poder dir que es fa bé la càrrega... (com amb PubMed, que el procés va ser més llarg...)

No sé, ja diràs...

gràcies!

Hola Marta,

entenc perfectament que les càrregues hagin de ser parcials, i si dieu de 50 en 50, fantàstic per tothom, m'hi apunto. Però vull prescindir que la informació bibliogràfica passi per un Excel, perquè mai no quedarà bé (la informació bibliogràfica poques vegades es pot codificar bé en un Excel; potser només en literatura), i a més, dificulta molt l'automatització. Si ja està catalogada a Scopus, fem una importació de Scopus al DDD, que quedarà molt millor.

Crec que seria molt millor triar la manera de fer les càrregues de Scopus al DDD, ja sigui d'alguna manera automatitzant aquests 50 en 50 (exemples: començar pels més antics fins que estiguin tots, ja sigui en tongades de 50 o per anys sencers, o altres idees), o bé amb una llista explícita de DOIs, carregats d'alguna manera que encara no sé. Però que tota la informació bibliogràfica vingui codificada de Scopus.

Potser serà millor parlar-ne per telèfon.

Perfecte Ferran!

Provaré de trucar-te demà (26/06/18)

Gràcies!

Marta,

Tal i com hem quedat, et passo un arxiu .txt amb la llista de DOI (n'hi ha 10) per a fer les proves de càrrega d'articles Scopus - DDD

De moment va bé, estic acabant-ho. De tota manera, un dels camps dels registres de Scopus és openaccess. Dos dels 10 registres tenen aquest camp a 0, en concret:

• 10.1088/2053-1583/aa7966 openaccess = 0
• 10.1002/smll.201603465 openaccess = 0

Entenc que els que no són openaccess no els podem carregar al DDD, oi? De moment no sé veure si hi ha informació d'embargament, però continuaré mirant.

Hola Ferran!

cal descarregar tots els registres de la llista, siguin open access o no. A diferència de PubMed aquí cal descarregar la producció científica de l'INC2 al complet, en obert o amb copyright.

• En cas d'articles que no siguin d'accés obert, l'ICN2 s'encarrega de subministrar la versió post-print en PDF. Per tant, en aquests casos cal descarregar la informació bibliogràfica en un registre DDD sense PDF i nosaltres pujarem a posteriori el PDF adequat, i embargarem si és necessari

• En el cas d'articles que ja detectis que són Open Access, si es pot descarregar la informació bibliogràfica + el PDF d'Scopus (i que quedi com els de PubMed), seria fantàstic

Hi ha dues coses que em vaig oblidar de preguntar-te:

1. en aquestes càrregues amb les quals fas proves, hi haurà control de duplicats? És a dir, si l'article ja es troba al DDD que no es descarregui un altre cop. Els de l'ICN2 em van dir que ells ens enviarien les coses que no estan al DDD, però un control extra de duplicats no estaria malament... amb PubMed ja es va fer així, si no m'erro (contrastant els DOI, no?)

2. entenc que els articles quedaran a la bústia REVISARCIE, oi? perquè si es posen a a REVISARCARAUT, quedaran barrejats amb els de PubMed...

Ja diràs!

Hola Marta,

en principi, sí a tot. Pel que fa al PDF, la veritat és que no m'ho he mirat, però ho investigaré.

Estic acabant de polir els registres, que ja es poden veure a https://ddd-test.uab.cat/collection/artpub

Me n'alegro que els hi hagi agradat. Pel que fa a la subvenció, m'ho estic mirant, i la informació està codificada, p. ex:

    <xocs:meta>
      <xocs:funding-list has-funding-info="1" pui-match="primary">
        <xocs:funding-addon-generated-timestamp>2018-06-18T23:35:22Z</xocs:funding-addon-generated-timestamp>
        <xocs:funding-addon-type>http://vtw.elsevier.com/data/voc/AddOnTypes/50.7/nlp</xocs:funding-addon-type>
        <xocs:funding>
          <xocs:funding-agency-matched-string>Metrology for Nanoscale Production</xocs:funding-agency-matched-string>
        </xocs:funding>
        <xocs:funding>
          <xocs:funding-agency-matched-string>Seventh Framework Programme NMPCall</xocs:funding-agency-matched-string>
          <xocs:funding-agency-acronym>FP7</xocs:funding-agency-acronym>
          <xocs:funding-agency>Seventh Framework Programme</xocs:funding-agency>
          <xocs:funding-agency-id>http://data.elsevier.com/vocabulary/SciValFunders/501100004963</xocs:funding-agency-id>
          <xocs:funding-agency-country>http://sws.geonames.org/6695072/</xocs:funding-agency-country>
        </xocs:funding>
        <xocs:funding>
          <xocs:funding-agency-matched-string>EC</xocs:funding-agency-matched-string>
          <xocs:funding-id>309558</xocs:funding-id>
          <xocs:funding-agency-acronym>EC</xocs:funding-agency-acronym>
          <xocs:funding-agency>European Commission</xocs:funding-agency>
          <xocs:funding-agency-id>http://data.elsevier.com/vocabulary/SciValFunders/501100000780</xocs:funding-agency-id>
          <xocs:funding-agency-country>http://sws.geonames.org/6695072/</xocs:funding-agency-country>
        </xocs:funding>
        <xocs:funding>
          <xocs:funding-agency-matched-string>MINECO</xocs:funding-agency-matched-string>
          <xocs:funding-id>SEV-2013-0295</xocs:funding-id>
          <xocs:funding-agency-acronym>MINECO</xocs:funding-agency-acronym>
          <xocs:funding-agency>Ministerio de Economía y Competitividad</xocs:funding-agency>
          <xocs:funding-agency-id>http://data.elsevier.com/vocabulary/SciValFunders/501100003329</xocs:funding-agency-id>
          <xocs:funding-agency-country>http://sws.geonames.org/2510769/</xocs:funding-agency-country>
        </xocs:funding>
        <xocs:funding-text>This work has been performed within the aim4np project (Automated in-line Metrology for Nanoscale
 Production), which is supported by the EC through a grant (contract Nr. 309558) within the Seventh Framework Programme NMPCall 
 2012.1.4-3 on Nanoscale mechanical metrology for industrial processes and products. ICN2 acknowledges support of the Spanish 
 MINECO through the Severo Ochoa Centers of Excellence Program under Grant SEV-2013-0295.</xocs:funding-text>
      </xocs:funding-list>
    </xocs:meta>

D'entrada, miraré que quedi com la que ja tenim als altres registres del DDD; Si falta alguna cosa ens ho repassem després.

Pel que fa a la 856, d'acord, tal com t'he fet la proposta veig que tampoc no és gaire pràctic. Deixa'm pensar-ho una mica i pensem una proposta que sigui millor per tothom. En parlarem.

Bon dia Ferran i Cristina:

D'acord amb una conversa amb la Cristina, he fet la prova de validació al ddd "normal" d'un registre del ddd-test provinent de la càrrega automàtica Scopus de l'ICN2. A través de: https://ddd.uab.cat/marcedit.py he copiat/enganxat el registre bibliogràfic del ddd-test excepte la 001 i la 005. A banda d'aquest copiar i enganxar, al registre hi he afegit la següent informació:

- camp 979 _ $a AUTSCOPUS
- canvis al camp 980 _ $9 ARTPUB $a REVISAR $b UAB $b REVISARCIE

Quan el registre ha entrat a REVISARCIE, he afegit el PDF, completat la 856 que el Ferran deixa mig embastada (Ferran, va genial!) i, a més, a la 979 hi he afegit el mail de la persona ICN2 que demana la càrrega del registre (recordem que és un autoarxiu, i com a tal ha de quedar registrat):

979 __ $9 ana.delaosa@icn2.cat $a AUTSCOPUS

he enviat el registre a publicar i l'Ana de la Osa confirma que ha rebut bé el mail automàtic de confirmació.

Per tant, jo crec que es podria posar automàticament l'etiqueta 979 __ $a AUTSCOPUS a tots els registres que vinguin per aquesta via.

Ferran, sé que estàs mirant el tema dels camps relacionats amb els grantAgreement. Els de l'ICN2 em demanen que els 9 registres que queden al ddd-test es publiquin ja. I, a més, ja m'han passat una llista de 30 DOIs nous per a la propera càrrega.

Si el tema grantAgreement encara no està llest, Ferran, què et sembla si processo al ddd els 9 que queden de la primera càrrega al ddd-test (ja afegirem els codis de subvenció manualment) i afegeixo a aquesta tasca wiki els següents 30 doi, amb els que pots mirar si es pot descarregar també aquest camp de finançament...

Ja diràs, gràcies!

Bon dia:

He detectat una incidència amb la càrrega Scopus - DDD. Avuí he passat un altre article del DDD-test al DDD, i mentre validava el registre me n'he adonat que, quan es carrega l'article d'Scopus, els autors 700 queden ordenats per filiació, no per ordre de signatura. Amb el que vaig processar ahir també em va passar, però no li vaig donar importància (pensant que era un error puntual d'aquell registre), però avui ha tornat a passar amb el segon registre. He mirat per sobre la resta de registres d'aquesta càrrega al DDD-test i vec que passa en tots ells.

Entenc que això passa perquè s'extreu la informació del camp "Authors with affiliations" d'Scopus, on els autors estan lligats amb la seva filiació i s'ordenen per filiació. Perquè en el registre Scopus que veiem quan consultem la base de dades apareix l'ordre correcte, perquè mostra la informació continguda en 2 altres camps:

- el camp "Authors" (on surten només els autors, ordenats per ordre de col·laboració en el document)
- el camp "Affiliations" (on mostra les filiacions per separat, sense lligar amb autors)

No sé si això es pot arreglar d'alguna manera... Mentre, el que he fet en els dos registres validats és ordenar les 700 manualment. No és que sigui un gran problema, però si es pot arreglar automàticament, estaria molt bé...

ja direu

Gràcies!

Hola!

he detectat una altra (petita) incidència en aquesta càrrega automàtica Scopus - DDD. Al DDD-test vec que el camp "Resum" té l'etiqueta

520 __ $a

quan hauria de ser

520 3_ $a

No sé si això és important o no, en tot cas, ho faig constar a la tasca

Gràcies!

Marta Jordan va escriure:

quan hauria de ser

520 3_ $a

Corregit, gràcies per fixar-t'hi!

Ferran Jorba va escriure:

Pel que fa a la subvenció, m'ho estic mirant, i la informació està codificada, p. ex:

[...]

D'entrada, miraré que quedi com la que ja tenim als altres registres del DDD; Si falta alguna cosa ens ho repassem després.

He fet el que he pogut amb les subvencions per codificar-les a la 536. Crec que està tot bé menys quan a Scopus no consta l'acrònim de la institució, i aleshores hi he de posar el nom, ex:

• https://ddd-test.uab.cat/record/176760/export/hm
• https://ddd-test.uab.cat/record/176758/export/hm
• https://ddd-test.uab.cat/record/176757/export/hm
  etc.

Marta Jordan va escriure:

Per tant, jo crec que es podria posar automàticament l'etiqueta 979 __ $a AUTSCOPUS a tots els registres que vinguin per aquesta via.

A partir d'ara ja hi és.

Marta Jordan va escriure:

I, a més, ja m'han passat una llista de 30 DOIs nous per a la propera càrrega.

Per poc que puguis, si en fas un fitxer .txt i me'l puges a la tasca, em servirà per tenir més casos de conversió, que segur que amb 10 no hauré cobert tota la varietat.

Marta Jordan va escriure:

He detectat una incidència amb la càrrega Scopus - DDD. Avuí he passat un altre article del DDD-test al DDD, i mentre validava el registre me n'he adonat que, quan es carrega l'article d'Scopus, els autors 700 queden ordenats per filiació, no per ordre de signatura.

Crec que ja està corregit.

Bon dia!

repassant aquesta càrrega hem detectat dos cosetes més (petites):

• Al camp 546, després de l'idioma apareix un punt:

546 __ $a Anglès.

Que crec que hauria de de desaparèixer:

546 __ $a Anglès

• D'altra banda a l'etiqueta 973 apareix un $t que, segons mirem amb els altres registres del DDD, no hauria d'aparèixer:

973 __ $f 1660 $l 1664 $m 3 $n 3 $t Nano Letters $v 17 $x 1530-6992_a2017m3v17n3 $y 2017

En els altres registres la 973 queda:

973 __ $f 1430 $l 1449 $m 3 $v 218 $x nph_a2018m3v218n $y 2018

No sé si aquest camp és necessari treure'l o es pot deixar..

Marta Jordan va escriure:

repassant aquesta càrrega hem detectat dos cosetes més (petites):

T'ho agraeixo; a mi al final se m'escapen.

• Al camp 546, després de l'idioma apareix un punt:

546 __ $a Anglès.

Que crec que hauria de de desaparèixer:

En aquest cas no, ha d'acabar en punt: https://www.loc.gov/marc/bibliographic/bd546.html. Dit això, estic veient que al DDD n'hi ha que no acaben en punt. Ja en faré una tasca a part, per normalitzar-les (la #5081).

• D'altra banda a l'etiqueta 973 apareix un $t que, segons mirem amb els altres registres del DDD, no hauria d'aparèixer:

Ben vist! Ja no hi és.

Marta, què et sembla un formulari com aquest per carregar DOIs?

https://ddd-test.uab.cat/dois.py

Només és per a ús intern, cal permís per editar registres per poder-lo executar, i ara per ara és una simulació que encara no processa res. Però m'interessa saber si amb aquesta informació et seria útil:

Ferran, em sembla una idea genial: seria molt còmode i fàcil de carregar registres!

Aniria estupendament aquesta eina...

Ferran Jorba va escriure:

Marta, què et sembla un formulari com aquest per carregar DOIs?

https://ddd-test.uab.cat/dois.py

Només és per a ús intern, cal permís per editar registres per poder-lo executar, i ara per ara és una simulació que encara no processa res. Però m'interessa saber si amb aquesta informació et seria útil:

Ferran Jorba va escriure:

He fet el que he pogut amb les subvencions per codificar-les a la 536. Crec que està tot bé menys quan a Scopus no consta l'acrònim de la institució, i aleshores hi he de posar el nom, ex:

• https://ddd-test.uab.cat/record/176760/export/hm
• https://ddd-test.uab.cat/record/176758/export/hm
• https://ddd-test.uab.cat/record/176757/export/hm
  etc.

Hola Ferran! en referència a la càrrega de subvencions, la via que poses d'exemple ens obliga, igualment, a haver d'obrir l'article i revisar les subvencions. Per exemple, el registre:

https://ddd-test.uab.cat/record/176760/export/hm

Ha carregat aquesta info:

536 _ $9 info:eu-repo/grantAgreement/7th Framework Programme/283883
536 _ $9 info:eu-repo/grantAgreement/Research Foundation-Flanders/2014-SGR-1015
536 _ $9 info:eu-repo/grantAgreement/Research Foundation-Flanders/FWO
536 _ $9 info:eu-repo/grantAgreement/MINECO/SEV-2013-0295

D'aquestes 4 etiquetes, només la 4 és correcta. La 1, s'ha d'arreglar, la 2 també (és AGAUR) però ja hauríem d'entrar al PDF per verificar, la 3 ens obligaria a entrar també al PDF per veure exactament què és i si cal posar-la en una 536 o no...

PROPOSTA: Scopus, en els camps relatius al finançament, hi ha aquesta informació:

<xocs:funding-text>This work has been performed within the aim4np project (Automated in-line Metrology for Nanoscale
Production), which is supported by the EC through a grant (contract Nr. 309558) within the Seventh Framework Programme NMPCall
2012.1.4-3 on Nanoscale mechanical metrology for industrial processes and products. ICN2 acknowledges support of the Spanish
MINECO through the Severo Ochoa Centers of Excellence Program under Grant SEV-2013-0295.</xocs:funding-text>

La proposta seria que aquest camp "funding text" anés a parar, amb la redacció tal i com està a Scopus, a una 500 __ $a. Aquest camp sembla que dóna la informació tal i com està redactada a l'article i, així, amb la informació en aquest camp 500 nosaltres ja faríem les 536 que correspongui. Crec que ens seria més fàcil i àgil això que no pas anar arreglant 536 ja fetes... Un cop fetes les 536, eliminaríem aquest camp 500 del registre.

Per cert, em diuen de l'ICN2 que hi ha registres Scopus que tenen el camp "funding text" i "funding text2": en aquests casos ens interessaria la info dels dos camps (no sé si és per una limitació de caracters en aquest camp i l'han de dividir en dos per poder posar tota la info quan el redactat és llarg...). No he trobat cap exemple d'això als 10 registres de la primera càrrega... ara et passare una altra remesa de DOI per carregar i així veurem si hi ha cap cas d'aquests (entre d'altres coses que puguin anar sorgint)

Ja diràs si et sembla viable aquesta proposta

Merci!

Marta Jordan va escriure:

La proposta seria que aquest camp "funding text" anés a parar, amb la redacció tal i com està a Scopus, a una 500 __ $a. Aquest camp sembla que dóna la informació tal i com està redactada a l'article i, així, amb la informació en aquest camp 500 nosaltres ja faríem les 536 que correspongui. Crec que ens seria més fàcil i àgil això que no pas anar arreglant 536 ja fetes... Un cop fetes les 536, eliminaríem aquest camp 500 del registre.

Sí, a més del que es pot fer (ja veig que és insuficient) amb la 536, no em costa res afegir una o més 500 amb els camps "funding text" i "funding text2" (que de moment no l'he vist, a veure si amb els següents 31 registres en surt algun).

De fet molts repositoris tenen aquestes dues etiquetes, una amb text natural i lliure (que seria la 500, dc.description.sponsorship) i una altra de codificada (la 536, dc.relation.projectID).

Exemple a la Pompeu: https://repositori.upf.edu/handle/10230/32493?show=full

Marta Jordan va escriure:

Adjunto arxiu amb 31 DOI per a carregar al DDD. Ferran, si us plau, diga'm si ho et va millor carregar-ho al DDD-test (per si s'han d'arreglar coses) o directament a REVISARCIE...

De moment, deixa-me'ls aquí, que em serviran per fer les proves d'importació amb https://ddd-test.uab.cat/dois.py i, si van bé a -test, probablement avui mateix ja ho podem passar al DDD públic i tu mateixa en fas les importacions i ho provem en real.

Hola Marta,

he fet un munt de proves a -test i j jo crec que ja hauria de funcionar. Prova primer només amb un o dos DOIs, comprova que funcioni bé, i ves carregant els altres: https://ddd.uab.cat/dois.py

Segurament sortiran coses que fins ara no havíem contemplat. Concretament, l'etiqueta funding-text2 jo encara no l'he vista, i per tant no sé exactament com està codificada en xml. Si veus alguna cosa que no està bé, si us plau apunta-la a la tasca.

I si ha quedat algun tema més antic que no està resolt, si us plau no deixis de reclamar-me'l, que si el resolem en sortirà beneficiat tothom.

Gràcies.

Bon dia:

Ferran, he començat a mirar al DDD-test la segona càrrega de registres i vec que de la llista de 30 articles només se n'han carregat 4... Ferran ho has programat així per fer càrregues petites? és que només els 4 primers que apareixen a la col·lecció ARTPUB del DDD-test corresponen als 30 que vaig posar en el document de la darrera càrrega. L'article que fa 5 ja pertany a la primera càrrega de 10 registres...

ja diràs si ha fallat res...

gràcies!

Marta Jordan va escriure:

Ferran, he començat a mirar al DDD-test la segona càrrega de registres i vec que de la llista de 30 articles només se n'han carregat 4...

No, el que ha passat és que estan a diferents col·leccions: alguns a artpub, altres a revisar de tal biblioteca, altres a altres biblioteques, altres es van perdre pel camí mentre retocava el programa, etc, perquè vaig estar provant totes les possibilitats que se'm van ocórrer. El que m'interessava és que el programa funcionés bé, no que els registres a -test quedessin ben carregats.

Jo entenc que ja ho pots fer al DDD públic, i si no funciona bé, m'avises.

Hola Ferran:

He provat de fer una càrrega de registres Scopus a través de https://ddd.uab.cat/dois.py. D'això fa més d'1 hora, i els registres encara no han arribat a REVISARCIE (que és l'opció que he triat).

És normal que trigui? Ho dic perquè les càrregues a través de https://ddd.uab.cat/marcedit.py són més ràpides

D'altra banda, he vist que per carregar registres a https://ddd.uab.cat/dois.py no cal estar identificat amb username i password al DDD... en canvi, per carregar registres amb https://ddd.uab.cat/marcedit.py sí que cal estar identificat...

Gràcies!

Marta Jordan va escriure:

He provat de fer una càrrega de registres Scopus a través de https://ddd.uab.cat/dois.py. D'això fa més d'1 hora, i els registres encara no han arribat a REVISARCIE (que és l'opció que he triat).

Ara ja està; m'havia oblidat d'instal·lar una utilitat al DDD públic. De tota manera, dels 5 dois, només se n'han carregat 3, els altres 2 ja existien, possiblement a Revisar. Els que s'han carregat són aquests:

• https://ddd.uab.cat/record/194817
• https://ddd.uab.cat/record/194818
• https://ddd.uab.cat/record/194819

És normal que trigui? Ho dic perquè les càrregues a través de https://ddd.uab.cat/marcedit.py són més ràpides

Hauria de ser aproximadament igual de ràpid; espero que ara sí.

D'altra banda, he vist que per carregar registres a https://ddd.uab.cat/dois.py no cal estar identificat amb username i password al DDD... en canvi, per carregar registres amb https://ddd.uab.cat/marcedit.py sí que cal estar identificat...

Ho repassaré, gràcies per fixar-t'hi.

Marta Jordan va escriure:

Tal i com em vas demanar, et passo enllaç a un article Scopus que té els camps funding text 1 i funding text 2:

Gràcies per l'exemple. Pel que he vist, en xml l'etiqueta continua dient <funding-text>, però n'hi ha dues, i a la primera, el text comença a amb el nombre 1; la segona no. L'he carregat al DDD de proves per veure com es comporta el meu convertidor i senzillament carrega dues 500, a més de totes les 536, és clar:

https://ddd-test.uab.cat/record/179305

És a dir, que fins que no es demostri el contrari, el programa el pot tractar igual que els altres.

Ferran Jorba va escriure:

Marta Jordan va escriure:

• Al camp 546, després de l'idioma apareix un punt:

546 __ $a Anglès.

Que crec que hauria de de desaparèixer:

En aquest cas no, ha d'acabar en punt: https://www.loc.gov/marc/bibliographic/bd546.html. Dit això, estic veient que al DDD n'hi ha que no acaben en punt. Ja en faré una tasca a part, per normalitzar-les (la #5081).

Hola Ferran! en referència al punt dins de la 546, em comenta la meva companya Susana que quan es carrega un document per formulari d'autoarxiu i després mires el registre MARC DDD, el punt no apareix en aquest camp. No sé si és el que heu d'arreglar segons la tasca #5081... no sé si els registres que no tenen punt és perquè s'han carregat per formulari i per aquesta via no es posa de manera automàtica aquest signe.

Ferran Jorba va escriure:

Ara ja està; m'havia oblidat d'instal·lar una utilitat al DDD públic. De tota manera, dels 5 dois, només se n'han carregat 3, els altres 2 ja existien, possiblement a Revisar. Els que s'han carregat són aquests:

• https://ddd.uab.cat/record/194817
• https://ddd.uab.cat/record/194818
• https://ddd.uab.cat/record/194819

Ferran, dels dos dois no carregats un em quadra: efectivament estava ja al DDD i jo n'era conscient, però el vaig posar a propòsit per veure si detectava els duplicats (sí, ok, ho admeto... vaig posar una trampa per veure si funciona...). Però l'altre doi no carregat no em quadra gens: el registre no està al DDD, ni públic ni a cap subcol·lecció de "revisar"... almenys jo no el localitzo. És aquest doi:

10.1038/ncomms10766

Saps per què no s'ha carregat? Ho torno a intentar? tu pots localitzar al DDD aquest document??

Ja diràs... gràcies!

Hola Marta,

Hola Ferran! en referència al punt dins de la 546, em comenta la meva companya Susana que quan es carrega un document per formulari d'autoarxiu i després mires el registre MARC DDD, el punt no apareix en aquest camp. No sé si és el que heu d'arreglar segons la tasca #5081

No és per la tasca #5081, sinó per un programa relacionat amb la #2857, que afegeix en forma de text (a la 546) la llengua, que per formulari només entra codificada (041). S'afegeix d'un dia per l'altre, automàticament.

Marta Jordan va escriure:

Ferran, dels dos dois no carregats un em quadra: efectivament estava ja al DDD i jo n'era conscient, però el vaig posar a propòsit per veure si detectava els duplicats (sí, ok, ho admeto... vaig posar una trampa per veure si funciona...).

Ben fet, totes les proves, benintencionades o malicioses, són benvingudes ;-). Com més en fem ara, menys sorpreses ens trobarem en el futur.

Però l'altre doi no carregat no em quadra gens: el registre no està al DDD, ni públic ni a cap subcol·lecció de "revisar"... almenys jo no el localitzo. És aquest doi:

10.1038/ncomms10766

Saps per què no s'ha carregat? Ho torno a intentar? tu pots localitzar al DDD aquest document??

M'ha costat, però ja ho he trobat. No ha trobat el duplicat per niu, sinó per un camp inventat meu de l'època de la migració de Decomate al DDD i que sovint ens és útil per detectar articles duplicats també d'Eina i altres importacions. No és perfecte, però quan va bé, s'agraeix. Es tracta del camp 035 $9 articleid, que consisteix en l'ISSN, el volum, el número i la primera pàgina de l'article. Ara que hi ha més d'un ISSN (paper i digital), que l'ISSN de vegades porta guionet i de vegades no, i que el número de la pàgina de vegades no hi és, és menys precís. Però en aquest cas ha servit per detectar que a la meva conversió aquest camp no es genera correctament. De fet, l'ha detectat com a duplicat de https://ddd.uab.cat/record/194818/export/hm, on en l'articleid (etiqueta 035) hi manca el número i la primera pàgina.

Ara miro de corregir l'antic i la conversió.

Ferran Jorba va escriure:

Ara miro de corregir l'antic i la conversió.

He intentat substituir el número de pàgina pel número d'article, que algunes editorials sembla que utilitzen. He reprocessat els 5 dois, i ara resulta que ha carregat els dos que abans deia que estaven duplicats:

• https://ddd.uab.cat/record/194835
• https://ddd.uab.cat/record/194836

Hauré de mirar si ara en detecta massa pocs...

Ferran Jorba va escriure:

Marta Jordan va escriure:

Ferran, dels dos dois no carregats un em quadra: efectivament estava ja al DDD i jo n'era conscient, però el vaig posar a propòsit per veure si detectava els duplicats (sí, ok, ho admeto... vaig posar una trampa per veure si funciona...).

Ben fet, totes les proves, benintencionades o malicioses, són benvingudes ;-). Com més en fem ara, menys sorpreses ens trobarem en el futur.

Li estic donant voltes al tema de la detecció de duplicats, i me n'he adonat que els que havia trobat fins ara eren per casualitat, per una implementació incompleta de l'articleid, sense pàgina.

De fet, Invenio detecta duplicats si coincideix o bé la 001 o bé la 035, i el doi està a la 024. Per tant, no podem confiar que detecti duplicat només pel doi. Aleshores, se m'acudeixen hi ha dues solucions: una de més específica i una de més genèrica.

1. L'específica seria que abans de arregar aquests registres fes una cerca per doi, a les col·leccions públiques o a les restringides.
2. L'altra seria generalitzar el que havia començat a fer específicament pels registres carregats per aquest programa, que és afegir a la 035 l'identificador Scopus (i, aprofitant, el de Web of Science), ex: https://ddd.uab.cat/record/187813/export/hm

Jo crec que la solució que a la llarga donarà més de sí és la segona. De fet, l'identificador Scopus i Wos ja el tenim a la base de dades interna (tasca #4950, que no he acabat de tancar perquè no m'acaba de convèncer com em queda). Si en comptes de tenir-los amagats els posem a la 035, d'entrada ens protegirà dels duplicats, que és el propòsit d'aquesta nota, però és que a més, podrem crear enllaços o donar informació que enriquiran el DDD. Ara, en aquesta base de dades hi tenim quasi 6.200 identificadors Scopus i 6.800 de WoS, i es va actualitzant automàticament cada dia a partir dels dois.

Ferran Jorba va escriure:

De fet, Invenio detecta duplicats si coincideix o bé la 001 o bé la 035, i el doi està a la 024. Per tant, no podem confiar que detecti duplicat només pel doi. Aleshores, se m'acudeixen hi ha dues solucions: una de més específica i una de més genèrica.

No vull entrar molt en el tema perquè la Marta i tu ho esteu analitzant molt bé, però a més d'incloure aquests identificadors, no podríem afegir la 024 del DOI a la 001 i la 035 per a que detectés possibles DOIs duplicats?

Hola Cristina,

No vull entrar molt en el tema perquè la Marta i tu ho esteu analitzant molt bé, però a més d'incloure aquests identificadors, no podríem afegir la 024 del DOI a la 001 i la 035 per a que detectés possibles DOIs duplicats?

Si et refereixes (no estic segur d'entendre't al 100%) que configuri Invenio perquè a més de la 035 tingui en compte la 024 per identificar registres externs duplicats, la resposta és que no, Invenio només permet una sola etiqueta, i combinant el $9 amb el $a (la 001 no és tant per identificador extern com intern, però el resultat ve a ser el mateix). De fet, els del Cern només hi havien pensat en quant a identificadors OAI, però òbviament funciona per qualsevol identificador extern.

## CFG_BIBUPLOAD_EXTERNAL_OAIID_TAG -- where do we store OAI ID tags            
## of harvested records?  Useful for matching when we harvest stuff             
## via OAI that we do not want to reexport via Invenio OAI; so records          
## may have only the source OAI ID stored in this tag (kind of like             
## external system number too).                                                 
CFG_BIBUPLOAD_EXTERNAL_OAIID_TAG = 035__a

## CFG_BIBUPLOAD_EXTERNAL_OAIID_PROVENANCE_TAG -- where do we store OAI SRC     
## tags of harvested records?  Useful for matching when we harvest stuff        
## via OAI that we do not want to reexport via Invenio OAI; so records          
## may have only the source OAI SRC stored in this tag (kind of like            
## external system number too). Note that the field should be the same of       
## CFG_BIBUPLOAD_EXTERNAL_OAIID_TAG.                                            
CFG_BIBUPLOAD_EXTERNAL_OAIID_PROVENANCE_TAG = 035__9

ok, gràcies per la resposta tan completa ;-)

Ferran Jorba va escriure:

Li estic donant voltes al tema de la detecció de duplicats, i me n'he adonat que els que havia trobat fins ara eren per casualitat, per una implementació incompleta de l'articleid, sense pàgina.

No sé ben bé com es crea aquesta 035 (i perdona si ara dic coses que no són correctes per desconeixement del funcionament intern del DDD), però aquest problema em sembla que tindrà tendència a augmentar: cada cop més ens trobem articles de revistes online que no tenen paginació i que s'identifiquen per un núm. d'article. Per tant, ens podem trobar cada cop més $a de 035 on les dades no tenen núm. de pàgina perquè no hi ha pàgina (que és el que li passava al registre ICN2 que no es va carregar amb el doi i no estava duplicat, però era molt similar a una altra 035).
De fet, aquest tema el volia plantejar a la propera reunió de Docència i Recerca, perquè al formulari d'autoarxiu no existeix un camp per posar el núm. d'article, i l'hem de posar manualment després a la 773 i 973 (com si fos la primera pàgina, però sense pàgina final).

Per tant no sé si la 035, per aquesta via, és un bon element per detectar duplicats.

De fet, Invenio detecta duplicats si coincideix o bé la 001 o bé la 035, i el doi està a la 024. Per tant, no podem confiar que detecti duplicat només pel doi. Aleshores, se m'acudeixen hi ha dues solucions: una de més específica i una de més genèrica.

1. L'específica seria que abans de arregar aquests registres fes una cerca per doi, a les col·leccions públiques o a les restringides.
2. L'altra seria generalitzar el que havia començat a fer específicament pels registres carregats per aquest programa, que és afegir a la 035 l'identificador Scopus (i, aprofitant, el de Web of Science), ex: https://ddd.uab.cat/record/187813/export/hm

Jo crec que la solució que a la llarga donarà més de sí és la segona. De fet, l'identificador Scopus i Wos ja el tenim a la base de dades interna (tasca #4950, que no he acabat de tancar perquè no m'acaba de convèncer com em queda). Si en comptes de tenir-los amagats els posem a la 035, d'entrada ens protegirà dels duplicats, que és el propòsit d'aquesta nota, però és que a més, podrem crear enllaços o donar informació que enriquiran el DDD. Ara, en aquesta base de dades hi tenim quasi 6.200 identificadors Scopus i 6.800 de WoS, i es va actualitzant automàticament cada dia a partir dels dois.

Sí, a mi també m'agrada aquesta segona opció, i més si implica una millora de les prestacions del DDD... aquesta opció implica molt de temps per a què la desenvolupis?

gràcies!

Ferran Jorba va escriure:

He intentat substituir el número de pàgina pel número d'article, que algunes editorials sembla que utilitzen. He reprocessat els 5 dois, i ara resulta que ha carregat els dos que abans deia que estaven duplicats:

• https://ddd.uab.cat/record/194835

Aquest és realment el duplicat, el que vaig posar com a trampa i no es va carregar inicialment. Ja està al DDD, puc eliminar aquest registre de REVISARCIE??

• https://ddd.uab.cat/record/194836
  Hauré de mirar si ara en detecta massa pocs...

I aquest és el que no estava duplicat i que s'havia d'haver carregat, el que ha iniciat el debat de si la 035 és prou o no per detectar duplicats... el validaré

Hola Ferran

Entre tot el debat de la detecció de duplicats... puc seguir carregant dois a través de https://ddd-test.uab.cat/dois.py ?? Per anar avançant... i de pas podríem veure si hi ha més casos de mala detecció de duplicats...

Ja diràs

Gràcies!

Hola Marta,

sí, pots anar carregant via https://ddd.uab.cat/dois.py (no https://ddd-test.uab.cat/dois.py). De fet, ahir ja vaig preparar el sistema per afegir els identificadors externs de Scopus i WoS a la 035, i ja en tenim prop d'un miler. Dels aproximadament 6000, calculo que entre avui i demà ja els hauré pogut carregar tots, i per tant, la detecció de duplicats de les càrregues de Scopus ho farà via identificador de Scopus:

• https://ddd.uab.cat/search?p=scopus_id&sc=1
• https://ddd.uab.cat/search?p=wos_id&sc=1
• https://ddd.uab.cat/search?p=pmid&sc=1

Una de les coses que no recordo haver-me fixat és si Scopus també dóna identificadors com els de pmid o pmc, per afegir més seguretat al tema, a part d'enriquir millor els nostres registres.

Marta Jordan va escriure:

Ferran Jorba va escriure:

He intentat substituir el número de pàgina pel número d'article, que algunes editorials sembla que utilitzen. He reprocessat els 5 dois, i ara resulta que ha carregat els dos que abans deia que estaven duplicats:

• https://ddd.uab.cat/record/194835

Aquest és realment el duplicat, el que vaig posar com a trampa i no es va carregar inicialment. Ja està al DDD, puc eliminar aquest registre de REVISARCIE??

Sí, ja el pots eliminar, després de donar-li les gràcies efusivament. Va fer molt bé la seva funció ;-)

• https://ddd.uab.cat/record/194836
  Hauré de mirar si ara en detecta massa pocs...

I aquest és el que no estava duplicat i que s'havia d'haver carregat, el que ha iniciat el debat de si la 035 és prou o no per detectar duplicats... el validaré

Perfecte.

Aquest cap de setmana s'han acabat d'actualitzar tots els 035 d'aquells registres que tenen DOI amb els identificadors de Scopus, WoS i Altmetric:

• https://ddd.uab.cat/search?p=scopus_id&sc=1
• https://ddd.uab.cat/search?p=wos_id&sc=1
• https://ddd.uab.cat/search?p=altmetric_id&sc=1
• https://ddd.uab.cat/search?p=pmid&sc=1

Amb això no haurien d'entrar duplicats de càrregues de Scopus ni, en el futur, si ho fem, de Web of Science. I obre opcions a fer coses noves amb els registres, com, per exemple, fer-hi enllaços sempre, com ja fem amb els DOIs o els de PMID. O no. Però la dada la tenim, i s'anirà actualitzant diàriament.

Hola Marta,

Acabo de sol·licitar la càrrega de 34 articles d'Scopus al DDD a través de l'eina: https://ddd.uab.cat/dois.py. Però el sistema només n'ha carregat 9, de la resta no en diu res. Adjunto en aquesta tasca el mail d'alerta que he rebut sobre la càrrega. Què ha pogut passar amb la resta d'articles?.

En primer lloc, gràcies per adjuntar el missatge exacte, això sempre ajuda a esbrinar què pot haver passat :-)

Efectivament, a la teva llista hi ha els 34 dois, i acabo de comprovar que s'han recuperat 34 registres de Scopus en el seu format xml. Però només se n'han convertit 9 a marcxml. Per tant, entenc que el problema està en el conversor, que potser no ha sabut distingir on acaba un registre i comença un altre, o algun altre problema. M'ho miraré, però no cal que tornis a carregar-los perquè ja els tenim, tant la llista de dois com els registres de Scopus.

Hola Ferran!

Has pogut esbrinar perquè no es van carregar tots els articles de la càrrega de la setmana passada? Tinc una altra càrrega pendent, la puc tirar endavant?

Gràcies!

Marta Jordan va escriure:

Has pogut esbrinar perquè no es van carregar tots els articles de la càrrega de la setmana passada? Tinc una altra càrrega pendent, la puc tirar endavant?

Ho sento, no m'hi he posat. Dóna'm un dia més, si us plau.

Marta Jordan va escriure:

Has pogut esbrinar perquè no es van carregar tots els articles de la càrrega de la setmana passada? Tinc una altra càrrega pendent, la puc tirar endavant?

Ja està corregit. L'explicació és que com que (pel que em sembla entendre) els registres de Scopus provenen en bona part de la informació bibliogràfica generada pels editors, no són tots uniformes. Hi ha petites irregularitats que, fins que no me les trobo, no hi puc pensar. Avui n'he corregit dues, i amb això he pogut carregar els 25 registres que faltaven de la càrrega de 34.

El què he fet és que si torna a passar, tant qui faci la càrrega com jo mateix rebrem un correu amb el missatge d'error que em permeti corregir-lo, amb un títol del tipus Errors a la conversió del fitxer dois_a2018m9d7_120902.xml a Marc21 i un contingut com ara aquest:

[...]
#scopus2marc: converting doi 10.1515/nanoph-2016-0101, scopus_id 85002198086 to Marc21
#scopus2marc: converting doi 10.1039/c6cc02959k, scopus_id 84974621981 to Marc21
#Warning: scopus_id 84974621981 has no keywords
#scopus2marc: converting doi 10.1103/PhysRevB.93.115404, scopus_id 84960910301 to Marc21
#Warning: scopus_id 84960910301 has no keywords
#scopus2marc: converting doi 10.1002/jbio.201600154, scopus_id 84994541269 to Marc21
Traceback (most recent call last):
  File "/home/ddd/bin/scopus2ddd.py", line 379, in <module>
    scopus2marc(scopus_records[doi], collections, marcxml=marcxml)
  File "/home/ddd/bin/scopus2ddd.py", line 158, in scopus2marc
    authors = get_authors_list(scopus)
  File "/home/ddd/bin/scopus2ddd.py", line 49, in get_authors_list
    author2affiliations =  get_author2affiliations(scopus)
  File "/home/ddd/bin/scopus2ddd.py", line 37, in get_author2affiliations
    author_group['affiliation']['organization'])
TypeError: string indices must be integers

Per tant, avui ja pots fer la propera càrrega i mirarem si dóna errors o no ;-)

Hola Ferran!

gràcies per mirar-t'ho. Ara he fet la següent càrrega (era molt petita, consistia en 8 registres) i només se m'han carregat 5. He rebut el missatge de la càrrega (el que rebo sempre) i no diu res dels que falten (ni que són duplicats, ni res). He rebut això:

---log---
2018-09-18 09:50:30 --> Task #507693 started.
2018-09-18 09:50:30 --> Input file '/home/ddd/tmp/dois_a2018m9d18_095013.marcxml', input mode 'insert'.
2018-09-18 09:50:30 --> https://ddd.uab.cat/record/195676 DONE
2018-09-18 09:50:31 --> https://ddd.uab.cat/record/195677 DONE
2018-09-18 09:50:31 --> https://ddd.uab.cat/record/195678 DONE
2018-09-18 09:50:31 --> https://ddd.uab.cat/record/195679 DONE
2018-09-18 09:50:31 --> https://ddd.uab.cat/record/195680 DONE
2018-09-18 09:50:31 --> Task stats: 5 input records, 0 updated, 5 inserted, 0 errors, 0 inserted to holding pen. Time 1.38 sec.
2018-09-18 09:50:31 --> Task #507693 finished. [DONE]
---err---
---eof---

No he rebut cap altre missatge relatiu als errors a la conversió del fitxer que esmentaves en el teu darrer comentari...

Gràcies!

Hola Marta,

doncs resulta que hi havia tres dois que el programa no ha trobat a Scopus. A partir d'ara, si torna a passar, t'enviarà a tu (i a mi) un correu amb el missatge corresponent. El d'ahir era aquest:

#request: http://api.elsevier.com/content/abstract/doi/10.1103/PhysRevMaterials.1.044006
Error: 10.1103/PhysRevMaterials.1.044006 not found in Scopus
#request: http://api.elsevier.com/content/abstract/doi/10.1088/2053-1583/aab568
#request: http://api.elsevier.com/content/abstract/doi/10.1021/acs.jpcb.7b03475
#request: http://api.elsevier.com/content/abstract/doi/10.1021/acs.cgd.7b00525
#request: http://api.elsevier.com/content/abstract/doi/10.1103/PhysRevB.96.035202
#request: http://api.elsevier.com/content/abstract/doi/10.1021/acsanm.8b00341
Error: 10.1021/acsanm.8b00341 not found in Scopus
#request: http://api.elsevier.com/content/abstract/doi/10.1039/c8nr02762e
#request: http://api.elsevier.com/content/abstract/doi/10.1103/PhysRevMaterials.2.054602
Error: 10.1103/PhysRevMaterials.2.054602 not found in Scopus
#scopus2marc: converting doi 10.1088/2053-1583/aab568, scopus_id 85045768864 to Marc21
#scopus2marc: converting doi 10.1039/c8nr02762e, scopus_id 85051989282 to Marc21
#scopus2marc: converting doi 10.1021/acs.cgd.7b00525, scopus_id 85028948916 to Marc21
#scopus2marc: converting doi 10.1021/acs.jpcb.7b03475, scopus_id 85040787499 to Marc21
#scopus2marc: converting doi 10.1103/PhysRevB.96.035202, scopus_id 85026448874 to Marc21
#Warning: scopus_id 85026448874 has no keywords

Ferran Jorba va escriure:

Hola Marta,

doncs resulta que hi havia tres dois que el programa no ha trobat a Scopus. A partir d'ara, si torna a passar, t'enviarà a tu (i a mi) un correu amb el missatge corresponent.

gràcies Ferran! està molt bé la idea del mail amb report de tot el que passa..

Bon dia Ferran:

He provat de carregar 4 dois a través de https://ddd.uab.cat/dois.py i no ha fet la càrrega. He rebut el següent missatge:

#request: http://api.elsevier.com/content/abstract/doi/10.1002/adfm.201606424
#request: http://api.elsevier.com/content/abstract/doi/10.1039/c7gc03132g
#request: http://api.elsevier.com/content/abstract/doi/10.1039/c7cc07052g
#request: http://api.elsevier.com/content/abstract/doi/10.1021/acssuschemeng.8b03180
#scopus2marc: 10.1021/acssuschemeng.8b03180 subtypeDescription = Article in Press
#scopus2marc: converting doi 10.1021/acssuschemeng.8b03180, scopus_id 85054176637 to Marc21 Traceback (most recent call last):
  File "/home/ddd/bin/scopus2ddd.py", line 383, in <module>
    scopus2marc(scopus_records[doi], collections, marcxml=marcxml)
  File "/home/ddd/bin/scopus2ddd.py", line 235, in scopus2marc
    host_item_entry = get_host_item_entry(bibrecord)
  File "/home/ddd/bin/scopus2ddd.py", line 88, in get_host_item_entry
    if 'pagerange' in source['volisspag']:
KeyError: 'volisspag'

No entenc quin és l'error, he comprovat que els 4 dois estan a Scopus correctament identificats....

Ja diràs què pot ser

Gràcies!

Marta Jordan va escriure:

He provat de carregar 4 dois a través de https://ddd.uab.cat/dois.py i no ha fet la càrrega. He rebut el següent missatge:

D'aquests missatges també en rebo còpia, no cal posar-los a la tasca. Com que, tal com he comentat més d'un cop, els registres de Scopus no són ben bé homogenis (sospito que és perquè recullen la part catalogràfica dels propis editors), de vegades el conversor a Marc21 es troba amb casos no contemplats. En aquest cas es tractava que no tenia camp de volum i número; fins ara me l'havia trobat sempre; ara ja tindrà en compte que no sempre hi és. He corregit el programa, els registres ja estan carregats, i tu ja tens el correu amb la conversió.

Gràcies Ferran per arreglar aquesta darrera càrrega!

D'altra banda, l'altre dia em vaig adonar que amb les càrregues Scopus, les etiquetes 100 i 700 tenen el segon indicador del subcamp amb el núm. 0:

100 10
700 10 (Exemple: https://ddd.uab.cat/record/195676)

Però si carreguem un article pel formulari d'autoarxiu, aquest indicador està buit:

100 1_
700 1_ (Exemple: https://ddd.uab.cat/record/195760)

He comprovat que això també passa amb les càrregues automàtices de PubMed: Exemple, https://ddd.uab.cat/record/195605

No sé si això és molt important o no... en tot cas, em sap greu no haver-m'hi fixat abans (sobretot pel que fa a la càrrega de PubMed, que la vam treballar fa temps...)

Gràcies!

Gràcies per fixar-t'hi. El segon indicador, tant de la 100 com de la 700, hauria de ser blanc (http://www.bnc.cat/sprof/normalitzacio/marc21bf/bf100.html). Els nous ja sortiran correctes, miraré de corregir els antics.

Bon dia Ferran!

Utilitzo aquesta tasca wiki per a incidències amb les carregues de dois d'Scopus... no sé si preferiries tancar aquesta tasca perquè està relacionada amb l'ICN2 i obrir una nova només per a incidències amb dois/Scopus...

A través de la URL https://ddd.uab.cat/dois.py he carregat una 29 dois. He rebut dos missatges de mompou relacionats amb la càrrega:

• un és el que em diu cada un dels registres carregats, aparentment tots exitosos. Però he constatat que no els ha carregat tots, només n'ha fet 24. Normalment en aquest mail, quan no et carrega algun, ho indica, però no diu res del 5 que falten. El mail és aquest:

---log---
2018-12-17 10:49:44 --> Task #533210 started.
2018-12-17 10:49:44 --> Input file '/home/ddd/tmp/dois_a2018m12d17_104857.marcxml', input mode 'insert'.
2018-12-17 10:49:44 --> https://ddd.uab.cat/record/200181 DONE
2018-12-17 10:49:44 --> https://ddd.uab.cat/record/200182 DONE
2018-12-17 10:49:45 --> https://ddd.uab.cat/record/200183 DONE
2018-12-17 10:49:45 --> https://ddd.uab.cat/record/200184 DONE
2018-12-17 10:49:45 --> https://ddd.uab.cat/record/200185 DONE
2018-12-17 10:49:45 --> https://ddd.uab.cat/record/200186 DONE
2018-12-17 10:49:45 --> https://ddd.uab.cat/record/200187 DONE
2018-12-17 10:49:45 --> https://ddd.uab.cat/record/200188 DONE
2018-12-17 10:49:45 --> https://ddd.uab.cat/record/200189 DONE
2018-12-17 10:49:45 --> https://ddd.uab.cat/record/200190 DONE
2018-12-17 10:49:45 --> https://ddd.uab.cat/record/200191 DONE
2018-12-17 10:49:45 --> https://ddd.uab.cat/record/200192 DONE
2018-12-17 10:49:46 --> https://ddd.uab.cat/record/200193 DONE
2018-12-17 10:49:46 --> https://ddd.uab.cat/record/200194 DONE
2018-12-17 10:49:46 --> https://ddd.uab.cat/record/200195 DONE
2018-12-17 10:49:46 --> https://ddd.uab.cat/record/200196 DONE
2018-12-17 10:49:46 --> https://ddd.uab.cat/record/200197 DONE
2018-12-17 10:49:46 --> https://ddd.uab.cat/record/200198 DONE
2018-12-17 10:49:46 --> https://ddd.uab.cat/record/200199 DONE
2018-12-17 10:49:46 --> https://ddd.uab.cat/record/200200 DONE
2018-12-17 10:49:47 --> https://ddd.uab.cat/record/200201 DONE
2018-12-17 10:49:47 --> https://ddd.uab.cat/record/200202 DONE
2018-12-17 10:49:47 --> https://ddd.uab.cat/record/200203 DONE
2018-12-17 10:49:47 --> https://ddd.uab.cat/record/200204 DONE
2018-12-17 10:49:47 --> Task stats: 24 input records, 0 updated, 24 inserted, 0 errors, 0 inserted to holding pen. Time 3.65 sec.
2018-12-17 10:49:47 --> Task #533210 finished. [DONE]
---err---
---eof---

• però també he rebut un altre mail, que no havia vist abans, és bastant llarg:

#request: http://api.elsevier.com/content/abstract/doi/10.1021/acs.jpcc.6b05465
#request: http://api.elsevier.com/content/abstract/doi/10.1103/PhysRevLett.117.176602
#request: http://api.elsevier.com/content/abstract/doi/10.1103/PhysRevB.94.165305
#request: http://api.elsevier.com/content/abstract/doi/10.1088/2053-1583/3/3/035016
#request: http://api.elsevier.com/content/abstract/doi/10.1002/ejic.201600511
#request: http://api.elsevier.com/content/abstract/doi/10.1063/1.4936757
#request: http://api.elsevier.com/content/abstract/doi/10.1103/PhysRevB.91.235139
#request: http://api.elsevier.com/content/abstract/doi/10.1021/acsami.5b00632
#request: http://api.elsevier.com/content/abstract/doi/10.1103/PhysRevB.91.035437
#request: http://api.elsevier.com/content/abstract/doi/10.1021/la504906q
#request: http://api.elsevier.com/content/abstract/doi/10.1109/TMAG.2014.2358939
#request: http://api.elsevier.com/content/abstract/doi/10.1021/nl504446r
#request: http://api.elsevier.com/content/abstract/doi/10.1021/acs.nanolett.5b00708
#request: http://api.elsevier.com/content/abstract/doi/10.1021/acs.nanolett.5b01021
#request: http://api.elsevier.com/content/abstract/doi/10.1103/PhysRevB.91.205440
#request: http://api.elsevier.com/content/abstract/doi/10.1002/adfm.201500016
#request: http://api.elsevier.com/content/abstract/doi/10.1039/c5nr02905h
#request: http://api.elsevier.com/content/abstract/doi/10.1021/nl504437v
#request: http://api.elsevier.com/content/abstract/doi/10.1021/acs.jpcc.5b01263
#request: http://api.elsevier.com/content/abstract/doi/10.1021/acs.jpcc.5b01839
#request: http://api.elsevier.com/content/abstract/doi/10.1016/j.bios.2014.05.066
#request: http://api.elsevier.com/content/abstract/doi/10.1103/PhysRevB.91.165117
#request: http://api.elsevier.com/content/abstract/doi/10.1021/jz5026118
#request: http://api.elsevier.com/content/abstract/doi/10.1039/c4nr07191c
#request: http://api.elsevier.com/content/abstract/doi/10.1039/c5tb00545k
#request: http://api.elsevier.com/content/abstract/doi/10.1016/j.bios.2014.07.086
#request: http://api.elsevier.com/content/abstract/doi/10.4028/www.scientific.net/MSF.897.151
#request: http://api.elsevier.com/content/abstract/doi/10.4028/www.scientific.net/MSF.897.155
#request: http://api.elsevier.com/content/abstract/doi/10.1016/j.bios.2015.05.050
#scopus2marc: converting doi 10.1039/c5tb00545k, scopus_id 84933054646 to Marc21
#scopus2marc: converting doi 10.1088/2053-1583/3/3/035016, scopus_id 84992388294 to Marc21
#scopus2marc: converting doi 10.1109/TMAG.2014.2358939, scopus_id 84930506352 to Marc21
#scopus2marc: converting doi 10.1002/ejic.201600511, scopus_id 84979642966 to Marc21
#scopus2marc: converting doi 10.1021/acs.jpcc.5b01263, scopus_id 84930630378 to Marc21
#scopus2marc: converting doi 10.1063/1.4936757, scopus_id 84948808573 to Marc21
#scopus2marc: 10.4028/www.scientific.net/MSF.897.151 subtypeDescription = Conference Paper
#scopus2marc: converting doi 10.4028/www.scientific.net/MSF.897.151, scopus_id 85020070792 to Marc21
#scopus2marc: converting doi 10.1021/acs.nanolett.5b00708, scopus_id 84935908761 to Marc21
#scopus2marc: converting doi 10.1103/PhysRevB.91.235139, scopus_id 84935094855 to Marc21
Warning: scopus_id 84935094855 has no keywords
#scopus2marc: 10.4028/www.scientific.net/MSF.897.155 subtypeDescription = Conference Paper
#scopus2marc: converting doi 10.4028/www.scientific.net/MSF.897.155, scopus_id 85020102277 to Marc21
#scopus2marc: converting doi 10.1103/PhysRevB.94.165305, scopus_id 84992045361 to Marc21
Warning: scopus_id 84992045361 has no keywords
#scopus2marc: converting doi 10.1021/acs.jpcc.5b01839, scopus_id 84930959965 to Marc21
#scopus2marc: converting doi 10.1002/adfm.201500016, scopus_id 84929093437 to Marc21
#scopus2marc: converting doi 10.1039/c5nr02905h, scopus_id 84937622573 to Marc21
#scopus2marc: 10.1016/j.bios.2015.05.050 subtypeDescription = Review
#scopus2marc: converting doi 10.1016/j.bios.2015.05.050, scopus_id 84930669883 to Marc21
#scopus2marc: converting doi 10.1103/PhysRevB.91.035437, scopus_id 84921764230 to Marc21
Warning: scopus_id 84921764230 has no keywords
#scopus2marc: converting doi 10.1103/PhysRevB.91.205440, scopus_id 84930225596 to Marc21
Warning: scopus_id 84930225596 has no keywords
#scopus2marc: converting doi 10.1021/la504906q, scopus_id 84926432292 to Marc21
#scopus2marc: converting doi 10.1021/acsami.5b00632, scopus_id 84926314125 to Marc21
#scopus2marc: converting doi 10.1021/jz5026118, scopus_id 84922588618 to Marc21
#scopus2marc: converting doi 10.1021/acs.jpcc.6b05465, scopus_id 84993982683 to Marc21
#scopus2marc: converting doi 10.1103/PhysRevLett.117.176602, scopus_id 84994045033 to Marc21
#scopus2marc: converting doi 10.1016/j.bios.2014.07.086, scopus_id 84922276307 to Marc21
#scopus2marc: converting doi 10.1021/nl504446r, scopus_id 84924535068 to Marc21
#scopus2marc: converting doi 10.1021/acs.nanolett.5b01021, scopus_id 84929208703 to Marc21 Traceback (most recent call last):
File "/home/ddd/bin/scopus2ddd.py", line 383, in <module>
scopus2marc(scopus_records[doi], collections, marcxml=marcxml)
File "/home/ddd/bin/scopus2ddd.py", line 162, in scopus2marc
authors = get_authors_list(scopus)
File "/home/ddd/bin/scopus2ddd.py", line 53, in get_authors_list
author2affiliations = get_author2affiliations(scopus)
File "/home/ddd/bin/scopus2ddd.py", line 45, in get_author2affiliations
author_initials = scopus_author['ce:initials']
KeyError: 'ce:initials'

Saps què ha passat amb els 5 que falten? Està relacionat amb el segon mail rebut?

ja diràs... Gràcies!

Hola Marta,

no, no cal que m'avisis d'aquestes incidències a través d'aquesta ni cap altra tasca. Tal com et vaig dir a la nota 29, jo ja en rebo còpia, dels correus (pots veure-ho tu mateixa en el propi missatge, que estic al CC).

T'he contestat per correu aquesta incidència. I sí, per mi pots tancar la tasca; els missatges d'error cada cop haurien de ser més esporàdics, i jo no en faria cap tasca.

Continuada a: #8449