Open omazapa opened 2 months ago
@restrepo queremos este campo? https://docs.openalex.org/api-entities/works/work-object#any_repository_has_fulltext
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' },
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 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
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'
},
exacto, Sí se puede poner el link en los dos lados.
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'
}
@restrepo dentro del diagrama no veo nada de "apc_paid", ¿ese campo lo tuviste en cuenta? ¿no lo queremos implementar?
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
@omazapa De acuerdo. Necesitamos el campo apc_paid
, no apc_list
. Ya lo he corregido en las slides.
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'
}
}
}
Se se quiere un campo adicional por favor re abrir el issue.
@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
@omazapa Datos que deben ir en la entidad de works, poner dentro del geo
de OpenAlex:
authors.affiliations.geo.city
authors.affiliations.geo.region # state or province or department
authors.affiliations.geo.country_code
authors.affiliations.geo.country
authors.affiliations.geo.latitude
authors.affiliations.geo.longitude
source.issn-l
source.is_in_doaj
@omazapa Por favor también
authors.affiliations.ror
Muchas gracias
@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
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:
- 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
- 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
Se agregan los campos de geo, countries, issn_l, ror y is_in_doaj en https://github.com/colav/quyca/pull/69
@joselomanuelo Hay datos sensibles expuestos en el API: https://github.com/colav/impactu/issues/341
@joselomanuelo el campo: bibliographic_info.bibtex
aún falta. Por ejemplo el Producto. qué esta en Google Scholar, debería tener ese campo
@joselomanuelo el campo:
bibliographic_info.bibtex
aún falta. Por ejemplo el Producto. qué esta en Google Scholar, debería tener ese campo
Profesor @restrepo esto se debe a que el campo bibtex del respectivo producto no viene en base de datos
@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
@omazapa @joselomanuelo Favor implementar en ETL:
@joselomanuelo el campo:
bibliographic_info.bibtex
aún falta. Por ejemplo el Producto. qué esta en Google Scholar, debería tener ese campoProfesor @restrepo esto se debe a que el campo bibtex del respectivo producto no viene en base de datos
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: https://docs.google.com/presentation/d/1UYNq2g5i-1IM_kMefEop7RXDT3h6rQNmvuPsPyu2OHI/edit#slide=id.g2246732a94e_1_0
@omazapa @joselomanuelo Favor incluir el dato de país de nacimiento:
En Scienti: SGL_PAIS_NACIM": "COL",
@omazapa @joselomanuelo Favor incluir la edad del autor:
en ETL ya está el campo
el cálculo de la edad se hace en backend
Se implementan los campos age y birth_country en https://github.com/colav/quyca/pull/76
@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.
[x] añadir nuevos tipo (crossref) del campo type_crossref
[x] poner doi como campo en la raiz del documento, cambio en kahi acá
[x] crear un nuevo campo open_access y sacar la información de openacess de bibliographic_info
[x] remover subtitle implementado acá
[x] oa_url ya está implementado acá
[x] añadir abstract de diferentes fuentes usando inverted_index
[x] añadir bibtext de scholar - implementado acá
[x] apc_paid
[x] citations_by_year
Slide link