In this task, you are given a set of paper reviews in English and Spanish language. Based on given reviews, your job is to generate decision, i.e., "accept" or "reject" for the given paper. Note that URLs in the text have been replaced with [Link].

Example Input: Review_1: Es una aplicación interesante, sin embargo los KPI no deben ser equivalentes a las medidas que finalmente quedarán en la tabla de hechos. Por ejemplo, el indicador promedio de defunciones por año, se debe implementar a través de la medida "cantidad de defunciones" que es una medida aditiva y se puede agregar por los distintos niveles de la dimensión (así puede obtenerse el KPI promedio por dia, mes, trimestre, etc). Hay varias dimensiones que están agrupadas en el modelo, siendo que son distintas (por ejemplo, caracteristica_madre). Se debe corregir el diseño, es posible que los resultados obtenidos por el sistema estén con errores. Review_2: El articulo presenta un análisis sobre las defunciones fetales en Mexico a través de un proceso de Inteligencia de Negocios (ETL - Datawarehouse - OLAP - KPI's) bien realizado. La debilidad se encuentra en la motivación del estudio, ya que no queda claro cómo surge y que induce a realizar el estudio, surge la inquietud de por qué en la UNAP se realiza un estudio que tiene que ver con muertes fetales en Mexico, ¿tendrán las conclusiones del estudio alguna repercusión en las políticas públicas de este país? o ¿es sólo un trabajo basado en datos abiertos?. Hubiera sido adecuado despejar estas dudas desde un comienzo de forma de valorar adecuadamente este trabajo. Review_3: 1.	Lo que se propone es interesante como una aplicación pero no es un trabajo científico. Además ya no es interesante la aplicación de un Datamart desde el punto de vista técnico como es presentado por el autor pues existe mucha documentación y trabajos al respecto. Por este motivo ahora hay que buscar "otros aspectos (diseño, metodología, etc.)" que hagan interesante un artículo del área Datamart.  2. Hay errores de diseño, por lo cual lo más probable es que los resultados que se muestran estén erróneos.  3. Debe tener cuidado con la sumarización. 
Example Output: accept

Example Input: Review_1: Evaluación general  El trabajo es interesante pero está mal planteado, faltan referencias importantes. Se sugiere revisar las referencias que se indican y extender el artículo mejorando su calidad en cuanto a la “forma” de plantear la comparativa, además de mostrar más ejemplos de los casos de estudio que le den mayor peso al artículo, con esto también podrá incorporar los trabajos futuros que son muchos y actualmente no aparece nada.  Correcciones de Formato  Las referencias no están en el formato que pide la revista Ingeniare, revisar formato y modificar.  La figura 1 es una ecuación y está fuera del formato que pide la revista Ingeniare.  Correcciones de Contenido  En la página 3 se hace referencia a [8] que es una tesis de grado, ¿qué tipo de grado?. Sería mejor referenciar a una metodología de artículo científico y eso daría  más "peso" al artículo. Cuando se habla de HL7/CDA se debería indicar una referencia para mayor información. No queda claro el uso de PGFOUNDRY  que es una extensión de postgreSql, ¿ se usó con Mysql?. Se debería haber sacado más provecho del uso de PGFOUNDRY. En el diseño del caso de estudio en la figura 5 hay errores graves en las relaciones entre las tablas Consulta y Paciente, entre las tablas Medicamento_Sintoma y Medicamento. No se indica en el artículo que el atributo duración es de tipo PERIOD, eso es importante. En los ejemplos de consultas hay un error en la consulta SGBDT, figura 7, ya que se indica el atributo periodo y el atributo es duración. Las conclusiones son muy evidentes y no plantean trabajos futuros que puedan ser interesantes de realizar. (Existe potencial y bastante que hacer) Faltan referencias importantes como por ejemplo: 1.	A review of temporal database research and its use in GIS applications. International Journal of Geographical Information Systems. Volume 3, Issue 3, 1989. 2.	Temporal Data and the Relational Model: A Detailed Investigation Into the ... Escrito por C. J. Date,Hugh Darwen,Nikos A. Lorentzos. 3.	A generalized model for a relational temporal database  Proceeding SIGMOD '88 Proceedings of the 1988 ACM SIGMOD international conference on Management of data… 4.	A glossary of temporal database concepts… Review_2: El artículo presenta un trabajo comparativo entre el uso de un SABD relacional clásico y un SABD temporal (la traducción al inglés temporary parece no adecuada: temporal o time oriented parece más correcto).  El ejemplo planteado en el artículo es interesante y motivador, esta adecuadamente sustentado y da pie a la comparación, como se indica "es necesario definir un escenario de pruebas donde exista una aplicación concreta que pueda ser evaluada con la implementación de los paradigmas a comparar".  Hay dos aspectos que en que el artículo no es claro, y que le restan peso:  1) La tecnología sabd temporal: pgFoundry, se indica que es una extensión a PostgreSql. Sin embargo, no se da mayor información... al buscarla parece un proyecto cerrado??? ¿cómo se trabajó con esta extensión?  2) La tabla 3 debería ser el centro del artículo, sin embargo no se describe como se realizaron muchas de las comparaciones. Quedando esto como una caja negra. ¿Qué criterios se utilizaron en las comparaciones? En las conclusiones hay algunas pistas, pero hay frases poco claras como: "Se puede encontrar una mayor flexibilidad de entrada de datos en el SGBDR, puesto que existen más tipos de fuentes para poblar las bases de datos." ¿Qué se quiere decir con esto? Review_3: Este artículo presenta una comparación, en base a una lista de criterios, de dos enfoques de bases de datos: relacional vs. temporal.  El artículo en general tiene un orden lógico y es legible. No obstante, la comparativa presenta al menos dos inconvenientes:  1) falta mucha información de cómo se obtuvieron los resultados de las tablas 3 y 4. Debe existir una descripción suficientemente detallada para luego poder replicar el trabajo.  2) El caso de estudio que se presenta forma la base de la comparación. Una real comparación debe sustentarse en una variedad de casos y dominios, para poder luego concluir con una base más amplia.  Sugiero abordar estos dos aspectos primero para sustentar mejor los resultados y conclusiones. 
Example Output: reject

Example Input: Review_1: Los autores presentan una aproximación para resolver problemas de programación de proyectos con recursos limitados (RCPSP) a través de un algoritmo de colonia artificial de abejas (ABC).  La idea parece relevante para el problema enfrentado. Sin embargo es importante hacer las siguientes mejoras al documento:  - Establecer claramente que la aplicación de ABC en RCPSP es algo que no se ha realizado antes. De no ser así, agregar un análisis comparativo de la solución propuesta frente a otras similares.  - El enlace [Link] está roto. Reemplazar por un enlace que no lo esté.  - En las tablas no es claro qué es el Makespan. Es la duración del schedule "canónico" para ese problema? Es la duración del schedule teórico óptimo? Es la duración del schedule del mejor algoritmo para es problema? Es la duración obtenida por el algoritmo ABC-RCPSP? Explicar esto con precisión  - Sería recomendable tener una descripción cuantitativa breve del desempeño del algoritmo en términos de tiempo vs tamaño del problema. Review_2: El trabajo presentado a Infonor - Chile, cumple con las expectativas siguientes: 1. Realiza una acertada discusión bibliográfica 2. Incorpora un algoritmo híbrido de búsqueda novedosa 3. Los resultados obtenidos con scheduling con restricciones usando el algoritmo (recursos limitados) muestra resultados alentadores. 
Example Output:
accept