Mantención de un historial de búsqueda y un resumen de sus resultados

[bassimat]

Sería interesante que en la etapa de análisis, cuando el investigador está descubriendo el área de dominio y probando la combinación de términos que mejor encamine su búsqueda, esta aplicación lo asista permitiendo comparar los resultados obtenidos.

Ejemplo de un ítem del historial:

• cadena de búsqueda
• nro de resultados obtenidos
  • nro de resultados por repositorio
• nro de resultados inspeccionados/revisados
• etc.

Otro issue podría ser la obtención de un reporte del historial que se pueda ordenar por sus campos

[JCMiguel]

Tarea a realizar en forma conjunta con @bassimat

[bassimat]

Ideas para el desarrollo de este issue

Caso de uso básico:

• Guardar los datos de cada búsqueda para poder recuperarlos más tarde.

Características:

• Los resultados de artículos de una búsqueda se guardan en un csv que, ahora, identifica el tiempo de la búsqueda (yymmddhhmmss)
• Cada búsqueda genera un registro asociado al tiempo del archivo csv de resultados
• El registro de búsqueda contiene un reporte con los siguientes datos:
  • ID que es igual al tiempo de la búsqueda.
  • Parámetros de entrada para la búsqueda (debe permitir reproducir la búsqueda)
  • Cantidad de resultados totales
  • Una columna más para cada repositorio y sus resultados en cantidad de artículos y porcentaje sobre el total.
  • Resumen de la distribución temporal de los resultados: Columna DeltaT01: % | DeltaT12: % | DeltaT23: %.
  • Otra forma de representarlo sería por porcentiles, ej: Col70%: 2018-2022 | Col25%: 2011-2017 | Col5%: 2023
  • Resumen de revisión
  • Cantidad de artículos descargados / revisados / fichados
• Los registros del historial se pueden recuperar ingresando los siguientes parametros:
  • Tiempo: Solo se ingresan los caracteres necesarios (se completa a izquiera o derecha con un guión). Ejemplo: -203010 sería solo hora.
  • Índice negativo: se indica con un - adelante y expresa la cantidad de búsquedas desde la última
  • Índice absoluto: cuenta desde la primer búsqueda registrada
  • Coincidencia: busca coincidencia de un texto ingresado con los registros guardados. Devuelve todos los que cumplen con match o de a uno si se busca de forma interactiva (-i)
• Los registros del historial se pueden etiquetar con ciertos términos (hasta 100 caracteres)

Características Potenciales:

• Obtener una diferencia de artículos entre dos registros de historial

Integración con el resto de la solución:

Despliegue:

Es un módulo con 3 clases dentro del ejecutable querier

Alta cohesion y bajo acoplamiento

1- En el método Repo.search() se obtienen los resultados que es importante registrar y, como desde fuera estos datos no son visibles se podrían retornar como un reporte. 2- Cada subclase de Repo tendrá un formato y nombre para esos datos, por lo tanto, será su responsabilidad recabar la información genérica para crear el reporte. De esta forma se baja el acoplamiento. 3- El resultado de la búsqueda se carga en un objeto Search que centraliza los resultados en forma de reportes. 4- Al finalizar la búsqueda este objeto creará un registro en el historial con toda la información recabada. 5- La gestión de todos los registros de búsquedas será responsabilidad de otra clase llamada historial (History) que implementará los casos de uso: Crear, recuperar, eliminar, comparar

[bassimat]

Una posible implementación para seguir las bases de bajo acoplamiento se muestra en historic.wsd:

[bassimat]

@JCMiguel dejé algo de material para que chequees y luego conversemos.

De todas las características/features que listé, podríamos implementar alguna parte, al menos al principio, y luego extenderlo. Lo digo por una cuestión de prioridades. Cuando lo conversemos consideramos entre esas y otras que se te ocurras y delimitamos el alcance.

[JCMiguel]

@bassimat No termino de entender cuál es tu propuesta de implementación. Te dejo expresadas algunas inquietudes basadas en el diagrama que compartiste en uno de tus comentarios.

• Según el diagrama, la clase Repo hereda de una clase Querier. ¿Esta clase qué función cumpliría?
• No termino de entender la diferencia de funcionalidad entre las clases Report y Search. Entiendo que cada implementación de Repo escribe un Report. Siendo así, ¿no sería Report la que centraliza la información? Acá es donde me pierdo.
• ¿Qué ideas tenés para centralizar los resultados de cada repositorio? ¿Pensás en un singleton, por ejemplo, o tenés en mente otra propuesta?

[bassimat]

Voy respondiendo a los ítems así llegamos con las ideas más claras para cuando lo conversemos:

• [ ] En realidad, esa relación (con flecha de rombo) significa agregación o composición, es decir, dentro del querier tenemos instanciados a los repos. Con esas dos entidades solo hago referencia a lo que ya tenemos funcionando del querier, por lo que no agregaría mayor funcionalidad, excepto la recolección de los resultados de búsqueda de los repos (ej: ieee.search( ) o pubmed.search( ) ) por medio de la clase Search. Luego explico un poco más este punto.
• [ ] Correcto, cada instancia de repo va a generar un reporte de los resultados particulares de su búsqueda y lo retorna en su método repo.search( ). Esta clase Report viene a ser más una estructura para agrupar esos datos que una clase con funcionalidad específica. Es más, en el caso de que su funcionalidad termine siendo nula podría repensarse como un diccionario y ya. En cuanto a Search, su función principal es generar el registro de la búsqueda que se guardará en el historial, y esta tendría los parámetros de búsqueda o cadena y el reporte general, que sería la recolección de los reportes particulares. En fin, tendría todos los datos de la búsqueda que se guarden en el historial. La clase History tiene el CRUD de lo registros y además un main para poder ejecutarse independientemente del querier.
• [ ] En el esquema que pensé, la centralización la haría la clase Search "appendeando" los sucesivos reportes. No me agrada mucho el Singleton porque puede haber reportes particulares de cada repo, entonces me parece medio forzado el patrón en este caso particular.

Nada de esto está puesto con 🗝️, por supuesto. Así que podemos moldearlo para que quede mejor. Luego lo seguimos conversando!

[bassimat]

Como se menciona aquí arriba, con el PR Integración de historial y clases Querier e Indexer mergeado, se cierra este issue