colav / impactu

Colav Impactu Issues and Documentation
BSD 3-Clause "New" or "Revised" License
0 stars 1 forks source link

[openalex] actualización de esquema kahi para integrar nuevos campos #278

Open omazapa opened 2 months ago

omazapa commented 2 months ago

@restrepo abajo pongo los cambios discutidos para el esquema de datos (data scheme) para el API de experto, si olvidé alguno por favor añadirlo en la lista. Los campos que discutamos en la reunión los voy a poner acá para tener claro la lista de cambios requeridos.

image

Slide link

omazapa commented 2 months ago

@restrepo queremos este campo? https://docs.openalex.org/api-entities/works/work-object#any_repository_has_fulltext

omazapa commented 2 months ago

así quedarían los datos de open_access

  external_urls: [
    {
      provenance: 'openalex',
      source: 'open_access',
      url: 'http://www.spog.org.pe/web/revista/index.php/RPGO/article/download/732/693'
    }
  ],
  bibliographic_info: { volume: '8', issue: '1-2', start_page: '79', end_page: '89' },
  open_access: { is_open_access: true, open_access_status: 'green' },
omazapa commented 2 months ago

así queda el typo crossref en el esquema de kahi

  types: [
    {
      provenance: 'openalex',
      source: 'openalex',
      type: 'article',
      level: null
    },
    {
      provenance: 'openalex',
      source: 'crossref',
      type: 'journal-article',
      level: null
    }
  ],
restrepo commented 2 months ago

@restrepo queremos este campo? https://docs.openalex.org/api-entities/works/work-object#any_repository_has_fulltext

De acuerdo, se puede adicionar para tener una información más detallada del estado de acceso abierto del producto

restrepo commented 2 months ago

así quedarían los datos de open_access

  external_urls: [ ...

@omazapa ¿Entonces external_urls.url, cuando external_urls.source es igual a 'open_access', corresponde a open_access.oa_url del OpenAlex? ¿Se podría poner el link en las dos partes?:

  external_urls: [
    {
      provenance: 'openalex',
      source: 'open_access',
      url: 'http://www.spog.org.pe/web/revista/index.php/RPGO/article/download/732/693'
    }
  ],
  bibliographic_info: { volume: '8', issue: '1-2', start_page: '79', end_page: '89' },
  open_access: { is_open_access: true, open_access_status: 'green' , oa_url: 'http://www.spog.org.pe/web/revista/index.php/RPGO/article/download/732/693'
  },
omazapa commented 2 months ago

exacto, Sí se puede poner el link en los dos lados.

omazapa commented 2 months ago

así queda el bibtex en bibliographic_info

  bibliographic_info: {
    volume: '134',
    start_page: '143',
    end_page: '145',
    pages: '2',
    bibtex: '@article{jaramillo1998ivermectin,\n' +
      '  title={Ivermectin for crusted Norwegian scabies induced by use of topical steroids},\n' +
      "  author={Jaramillo-Ayerbe, Felipe and Berr{\\'\\i}o-Mu{\\~n}oz, Joaqu{\\'\\i}n},\n" +
      '  journal={Archives of dermatology},\n' +
      '  volume={134},\n' +
      '  number={2},\n' +
      '  pages={143--145},\n' +
      '  year={1998},\n' +
      '  publisher={American Medical Association}\n' +
      '}\n'
  }
omazapa commented 2 months ago

@restrepo dentro del diagrama no veo nada de "apc_paid", ¿ese campo lo tuviste en cuenta? ¿no lo queremos implementar?

omazapa commented 2 months ago

respecto a apc_list y apc_paid

apc_list son solo lo que hay en doaj, nosotros ya lo tenemos y no es necesario para determinar los valores de los green.

respecto a apc_paid que es de donde podríamos sacar cuanto pagó en paper en una revista hibrida, sale de acá https://github.com/OpenAPC/openapc-de, donde solo tienen 225,940 papers para el corte de colombia son solo 1127 openalexco> db.works.countDocuments({"apc_paid.provenance":"openapc"}) 1127

¿integramos eso de todos modos? de tener que integrar algo, propongo solo poner el apc_paid el apc list mejor que siga en sources.

referencias apc_list https://docs.openalex.org/api-entities/works/work-object#apc_list apc_paid https://docs.openalex.org/api-entities/works/work-object#apc_paid

restrepo commented 2 months ago

@omazapa De acuerdo. Necesitamos el campo apc_paid, no apc_list. Ya lo he corregido en las slides.

omazapa commented 2 months ago

Así quedaran los datos de apc paid

  {
    apc: {
      paid: {
        value: 1435,
        currency: 'EUR',
        value_usd: 1547,
        provenance: 'openalex',
        source: 'openapc'
      }
    }
  },
  {
    apc: {
      paid: {
        value: 582,
        currency: 'EUR',
        value_usd: 627,
        provenance: 'openalex',
        source: 'openapc'
      }
    }
  }
omazapa commented 2 months ago

Se se quiere un campo adicional por favor re abrir el issue.

restrepo commented 1 month ago

@omazapa @joselomanuelo El schema de datos para el API de expertos está incluido en la siguiente slide. Favor poner en azul lo que se vaya implementando

ImpactU in OpenAlex

https://docs.google.com/presentation/d/1UYNq2g5i-1IM_kMefEop7RXDT3h6rQNmvuPsPyu2OHI/edit#slide=id.g2246732a94e_1_0

restrepo commented 1 month ago

@omazapa Datos que deben ir en la entidad de works, poner dentro del geo de OpenAlex:

@omazapa Por favor también

Muchas gracias

joselomanuelo commented 1 month ago

@omazapa @joselomanuelo El schema de datos para el API de expertos está incluido en la siguiente slide. Favor poner en azul lo que se vaya implementando

ImpactU in OpenAlex

https://docs.google.com/presentation/d/1UYNq2g5i-1IM_kMefEop7RXDT3h6rQNmvuPsPyu2OHI/edit#slide=id.g2246732a94e_1_0

Buen día profesor @restrepo, ya en el diagrama están de azul todos los campos que actualmente se entregan en la api, de verde están todos los campos que hace falta implementar, de esos verdes hay un subconjunto que se puede construir desde backend haciendo consultas entre varias colecciones de base de datos, no solo de works, esto podría ralentizar un poco la respuesta. Quisiera saber como he de proceder:

  1. Tratar de alimentar la respuesta con todos los posibles datos de otras colecciones
  2. Esperar a base de datos para saber que cosas vendran desde base de datos y construir el resto
  3. Recibir indicaciones por parte suya de que campos deben venir de base de datos y que otros campos se han de construir desde backend.
restrepo commented 1 month ago
  1. Recibir indicaciones por parte suya de que campos deben venir de base de datos y que otros campos se han de construir desde backend.

@joselomanuelo (@omazapa) Los únicos datos que se van a adicionar a works de momento son los reportados antes: https://github.com/colav/impactu/issues/278#issuecomment-2421025873

Los demás se deberían tomar de las otras entidades. Si hay algo que complique el pipeline o empeore la eficiencia se puede poner directamente en works

restrepo commented 1 month ago
  1. Recibir indicaciones por parte suya de que campos deben venir de base de datos y que otros campos se han de construir desde backend.

@joselomanuelo (@omazapa) Los únicos datos que se van a adicionar a works de momento son los reportados antes: #278 (comment)

@joselomanuelo @omazapa: Se propone que los datos geográficos estén dentro de affiliations.geo: Se ha actualizado la slide al respecto

joselomanuelo commented 2 weeks ago

Se agregan los campos de geo, countries, issn_l, ror y is_in_doaj en https://github.com/colav/quyca/pull/69

restrepo commented 1 week ago

@joselomanuelo Hay datos sensibles expuestos en el API: https://github.com/colav/impactu/issues/341

restrepo commented 1 week ago

@joselomanuelo el campo: bibliographic_info.bibtex aún falta. Por ejemplo el Producto. qué esta en Google Scholar, debería tener ese campo

image

joselomanuelo commented 1 week ago

@joselomanuelo el campo: bibliographic_info.bibtex aún falta. Por ejemplo el Producto. qué esta en Google Scholar, debería tener ese campo

image

Profesor @restrepo esto se debe a que el campo bibtex del respectivo producto no viene en base de datos Image

joselomanuelo commented 1 week ago

@joselomanuelo Hay datos sensibles expuestos en el API: #341

Queda solucionado en https://github.com/colav/quyca/pull/72 y en https://github.com/colav/quyca/pull/73

restrepo commented 1 week ago

@omazapa @joselomanuelo Favor implementar en ETL:

image

image

https://docs.google.com/presentation/d/1UYNq2g5i-1IM_kMefEop7RXDT3h6rQNmvuPsPyu2OHI/edit#slide=id.g2246732a94e_1_0

@joselomanuelo el campo: bibliographic_info.bibtex aún falta. Por ejemplo el Producto. qué esta en Google Scholar, debería tener ese campo image

Profesor @restrepo esto se debe a que el campo bibtex del respectivo producto no viene en base de datos Image

restrepo commented 1 week ago

El problema es que no aparece para todo lo que tiene Google Scholar:

Ver issue https://github.com/colav/impactu/issues/347

@joselomanuelo: Ya viene de base de datos pero no para todos los works:

kahi> db.works.countDocuments({"bibliographic_info.bibtex":{"$exists":1}})

98018

@omazapa @joselomanuelo Favor implementar en ETL: image image https://docs.google.com/presentation/d/1UYNq2g5i-1IM_kMefEop7RXDT3h6rQNmvuPsPyu2OHI/edit#slide=id.g2246732a94e_1_0

restrepo commented 1 week ago

@omazapa @joselomanuelo Favor incluir el dato de país de nacimiento:

image

En Scienti: SGL_PAIS_NACIM": "COL",

restrepo commented 1 week ago

@omazapa @joselomanuelo Favor incluir la edad del autor:

image

omazapa commented 1 week ago

en ETL ya está el campo

image

el cálculo de la edad se hace en backend

joselomanuelo commented 1 week ago

Se implementan los campos age y birth_country en https://github.com/colav/quyca/pull/76