Anexo metodológico. Detalles del desarrollo del script

Para obtener los datos de OA se trabajó en el desarrollo de un script
en Python, de instalación y ejecución local, que permite a partir
de un listado de nombre de personas (input) extraer los datos de las
publicaciones utilizando su API online. A fin de que el programa
pueda ser utilizado por otras personas siguiendo procedimientos
sencillos, como requerimiento se buscó que sea ejecutado desde cualquier
computadora y que su instalación y uso no requiera de conocimiento
experto. Se programó, entonces, pensando en que pudieran adaptarse
parámetros para delimitar búsquedas o ajustarlas para evaluar
resultados, sin necesidad de reescribir código.

Debido a que OA se encontraba en estado Beta al momento de la
utilización, se debieron sortear algunos inconvenientes que se considera
son inherentes a su fase de desarrollo, por ejemplo, que en ocasiones
respondía de manera distinta a una misma petición. También se
encontraron complicaciones al momento de buscar coincidencia entre los
nombres de autor producto, en muchos casos, de las particularidades del
idioma español (por ej. tildes y ñ) o cuestiones típicas de los nombres
(ej. apellidos compuestos, con preposición y apellidos de casadas), que
requirió del mayor desarrollo del código (ver detalle en anexo 1).
Asimismo, se detectó la existencia de varias entradas que resultaban
válidas para un mismo autor entremezcladas con otras incorrectas, lo
cual posiblemente se deba a la multiplicidad de fuentes que integran OA.
En conjunto con estos, se sumó la dificultad de la falta de tildes en
nombres y apellidos en el input, por lo que se requirió el armado de
un listado de nombres y apellidos que se acentúan con frecuencia para
agregarlos "programáticamente" con el script. 

Entre los inconvenientes que no pudieron ser salvados deben mencionarse:
la existencia de autores homónimos (o con nombres muy similares) como
para ser adecuadamente distinguidos automáticamente y los nombres
variantes, entre ellos, el uso indistinto de apellidos de casada y/o
soltera, las firmas con pseudónimos y las firmas que utilizan iniciales.

El script funciona armando variaciones de los nombres -con y sin tilde,
iniciales de nombre, etc.- y realiza múltiples peticiones a la API que
vuelven a ser filtradas descartando homónimos de otros países a partir
de las instituciones declaradas en las afiliaciones (parámetro
country_code). Se puede determinar un porcentaje mínimo de trabajos
del autor matcheado para considerarlo perteneciente al país seleccionado
(parámetro match_percentage). Cabe aclarar que, como limitación, se
han encontrado casos donde el país no está presente por lo que no se
puede hacer esta comprobación. Solo si un autor pasa estas
comprobaciones sus trabajos son tomados como válidos y agregados a la
base final. Si en esta comprobación los trabajos encontrados son muy
pocos, se hace una segunda vuelta de búsqueda hasta alcanzar un mínimo
establecido.

Algunas dificultades que fueron encontradas:

• Caracteres utf8, como tildes y la ñ, propios el lenguaje
  español, no son normalizados por el motor de búsqueda, por lo que
  búsquedas con nombres con tildes no matchean nombres sin él
  ("Pérez" ≠ "Perez"), y a la inversa. Esto es particularmente
  problemático si se tiene en cuenta que muchas veces esos tildes en
  los nombres propios y apellidos son removidos en las cargas de
  datos, y un mismo autor puede aparecer con y/o sin él
  indistintamente.

• En casos de mujeres, el uso del "de" (presentes sólo a veces)
  para incorporar apellidos de casada, siendo OA incapaz de
  vincular ambas variaciones ("Perez de Hernandez" ≠ "Perez
  Hernandez")

• Guiones medios como separador (presentes sólo a veces) de
  apellidos compuestos que el sistema no es capaz de "descartar" para
  realizar una comparativa ("Pérez*-*Hernández" ≠ "Pérez Hernández")

• Estas cuestiones, y otras posiblemente debidas a la multiplicidad de
  fuentes de las que se nutre OA, dan por resultado que existen muchas
  entradas válidas para un mismo autor, con lo que una búsqueda
  puede devolver múltiples entradas correctas que están cargadas como
  entidades diferentes, y entremezcladas con otras incorrectas. Y de
  esos datos, los que el sistema devuelve en primer lugar y califica
  como de mayor score (cuya lógica y funcionamiento no está
  aclarado) no es siempre el nombre que pareciera "coincidir" mejor
  (por lo que la utilización de ese campo fue descartado).

• OA es incapaz de matchear o "entender" correctamente las iniciales
  (modo en el que firman muchos autores). Entonces, puede encontrar
  coincidencias en nombres que claramente no debería ("Juan Alberto
  González" = "Juan C. González")

• Datos incompletos. Muchos trabajos no tienen el campo
  "institutions" y/o "country", con lo cual se complejiza estimar la
  nacionalidad del autor matcheado. Por otro lado, algunas veces el
  tipo de trabajo (si la publicación es o no un "journal-article", por
  ejemplo), tampoco está presente.

• Errores de tipeo en la carga de datos, aunque no muy común, se
  han encontrado entradas con nombres de autores mal escritos.

• Límite en la cantidad de peticiones diarias: 50.000 (única
  limitación conocida de antemano, que se encuentra aclarada en la
  documentación de la API), que en verdad no impacta en la calidad de
  los datos devueltos, sino en el tiempo que lleva ejecutar la
  descarga.

A partir de estas limitaciones de los datos y de la API, el proceso de
descarga/selección de cada autor que realiza el script consiste en lo
siguiente:

• Se lee el nombre de un autor con la siguiente estructura: "Apellido,
  Nombre1 Nombre2", utilizando la coma para determinar cuál es el
  apellido, y cuál/es el/los nombre/s

• Se busca la correspondencia del autor con el listado de nombres y
  apellidos que frecuentemente llevan tilde, y se crea una versión
  "tildada" del mismo. Ej: "Maria Sanchez" pasa a ser también "María
  Sánchez"

• Si el nombre/apellido en el listado original tenía tildes, se
  remueven, y se crea su versión sin tildes (caso inverso del ejemplo
  anterior)

• Una vez creadas las versiones con tilde y sin tilde, se
  generan distintas versiones de búsqueda: utilizando sólo el primer
  nombre del autor, sólo el segundo nombre, sólo el primer apellido,
  sólo el segundo, utilización de iniciales en ambos nombres, inicial
  en sólo el segundo, remoción del conector "de" para apellidos de
  mujeres casadas, y todas las variaciones y combinaciones entre cada
  variación que de esto surge, con y sin tilde. Esto significa que
  por cada autor se realiza una docena de variaciones (o más en
  algunos casos), sobre el nombre a buscar y allí se hace una petición
  múltiple que posteriormente volverá a ser filtrada.

• A partir de estos resultados, el script recorre cada autor
  devuelto y vuelve a hacer una comprobación de coincidencia entre lo
  que se buscó y lo que devolvió OA, refinando y reviendo las
  coincidencias.

• A partir de este filtrado final de autores, se realiza la búsqueda
  de los trabajos por cada matcheo, y se evalúan cuántos de estos
  fueron realizados con instituciones de Argentina, para "intuir" la
  nacionalidad del autor. Si los trabajos llegan al porcentaje
  deseado de correspondencia, se los considerará válidos, y de este
  modo se descartan muchos homónimos de otros países. Cabe aclarar,
  como limitación, que se han encontrado casos donde este campo no
  está presente y no se puede hacer esta comprobación.

• Sólo si un autor pasa estas comprobaciones sus trabajos son tomados
  como válidos y agregados a la base final. Y si en esta comprobación
  los trabajos encontrados son muy pocos, se hace una segunda vuelta
  de búsqueda hasta alcanzar un mínimo establecido.

Por otro lado, cabe destacar que para el desarrollo del código se han
tenido en cuenta las siguientes consideraciones generales:

- Que sea de fácil instalación/ejecución, incluso para usuarios no
expertos en el tema. Por esta razón se escoge hacerlo en lenguaje
Python, que además es de rápida escritura y fácil lectura, familiar en
muchos ámbitos y aplicaciones. Si bien Python es de ejecución "lenta" en
comparación a otros lenguajes, en este caso eso no afecta
sustancialmente el proceso, ya que la velocidad de la respuesta de la
API es la que en verdad dictamina los tiempos de ejecución.

-  Teniendo en cuenta que la descarga de un listado de unas 10.000
entradas puede llevar varias horas de ejecución, se evaluó como
fundamental la posibilidad de retomar la ejecución de un trabajo
inconcluso/incompleto, sea por crasheo de la API, la limitación de
peticiones diarias de la misma, corte abrupto de luz/internet, o incluso
nuevos elementos incorporados en el listado. El script va escribiendo en
bloque los trabajos del autor a medida que éste se evalúa cómo válido,
de este modo no se sobrecarga la memoria y en casos de cortes abruptos,
el trabajo "perdido" sería siempre de un solo autor.

- Debe poder correr en una pc normal sin grandes especificaciones
técnicas, incluso con listados grandes de autores. 

- Posibilidad de afinar/ajustar parámetros de búsqueda para evaluar
diferentes resultados sin necesidad de reescribir código, o incluso
adaptar el código a búsquedas futuras (se creó una hoja/archivo donde se
puede configurar parcialmente la ejecución). De este modo el script
puede ser adaptado a otras listas, otross tipo de filtros (de país, de
tipo de elemento, etc.) sin necesidad de reescribir código.

Gastón Zalba
2023/09/08