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].

Input: Consider Input: Review_1: Si bien este artículo deja ver una buena cantidad de trabajo, está escrito crípticamente y es muy difícil ver hacia donde apunta.  Hay problemas de redacción en:  Resumen (1): "falta de llaves y relaciones entre tablas y datos sino y por el contrario se genera rendimiento"  Fase 2 (8): "En este punto se realizaron los montajes de la base de datos en los dos (2) SGBD NoSQL en la nube. Y se montó el sistema gestor de bases de datos móvil que va a estar en comunicación con los montados en la nube."  Comportamiento... (9): "Para el caso de MongoDB, existe un ODBC desarrollado por estudiantes que está siendo desarrollado por estudiantes, y, otro ODBC desarrollado por Simba Technologies"  El artículo, en todo caso es muy difícil de seguir...  Comprensión: El título habla de una comparación..., sin embargo nunca se ve tal comparación.  "manejan el teorema CAP"... el teorema dice que hay tres características que no pueden darse simultáneamente, por lo que "manejan" no tiene sentido.  "desnormalizar los datos, es decir las propiedades ACID (atomicidad, consistencia, aislamiento y durabilidad) son sacrificadas por cuestión de rendimiento...", no veo una relación directa entre desnormalizar (un aspecto de diseño) con las propiedades acid (un conjunto de propiedades de las transacciones).  Se dice en un momento "Se eligieron dos sistemas gestores de bases de datos NoSQL alojados en la nube que son MongoDB y CouchDB; bases de datos a partir de las cuales se hacen las pruebas de transaccionalidad con el gestor de bases de datos móvil Ultralite", finalmente nunca se ven estas pruebas ni sus resultados.  Se dice "sin embargo las soluciones ODBC ya no son tan populares..." En que se sustenta esto???  Finalmente, se habla del uso de un middleware "Mobilink de Sybase" sin embargo, posteriormente se habla de problemas con contar con un odbc para los sabd noSQL (que requeriría Mobilink)... y de ultralite y la comparación no se sabe que paso...???? Review_2: El artículo describe muy bien los SGBD para móviles, así como también algunos motores de BD con tecnología no-relacional conocidas como NoSQL, en un contexto de almacenamiento de datos en la nube o cloud-computing. Realiza una  buena comparación de las características técnicas de algunos gestores de BD en este ámbito (tabla 3). Plantea una metodología, al parecer para definir y realizar un experimento que permita evaluar y comparar BD de este tipo, según lo definido en el título del artículo. Sin embargo,  sólo llega a establecer una comparación simple y cualitativa de componentes y otros aspectos como servicios (tabla 4). No hay evidencias de una comparación cuantitativa y objetiva, a nivel de desempeño y con datos, transacciones y tiempos de procesamiento que permitan realmente sostener, como lo hace sin estas variables, cual BD es más eficiente respecto a otra. El resumen no se condice ni identifica el trabajo completo. Las conclusiones se plantean en base a las características y no a pruebas comparativas de desempeño. En síntesis, es un trabajo desde el punto de vista que sería un aporte si formalizara la metodología y describiera la aplicación cuantitativa de una experimentación que realmente permita comparar los SGBD en un contexto de cloud-computing. Se sugiere complementar con un experimento controlado con datos y registro de transacciones de prueba y medir variables, obtener estadísticas objetivas que permitan evaluar los desempeños de los sistemas de BD móviles y NoSQL, bajo condiciones y parámetros claramente definidos y en las mismas condiciones medio-ambientales (ancho de banda, tas de transacciones, volumen de datos, equipo, etc). Review_3: El artículo presenta una revisión de los SGBD móviles y NoSQL.  No obstante lo anterior, el trabajo es más bien descriptivo y carece de resultados experimentales.  Lo que señala en la página 8, metodología, considera dos fases, de las cuales solo se presenta, al parecer los resultados de la primera fase.  Se sugiere realizar la segunda fase, que conlleva un trabajo experimental de recolección de datos y su análisis, y luego generar un artículo con estos resultados. 

Output: reject


Input: Consider Input: Review_1: Loa autores siguen las metodologías SEMMA y CRISP-DM para el desarrollo del proyecto. A lo largo del paper los autores van describiendo la fase de la metodología, el trabajo realizado y los resultados obtenidos en esa fase, excepto en la fase de minería de datos (y clustering) que los autores posponen la descripción del trabajo y de los resultados a la sección 5 del paper. Esto hace que la estructura del paper no sea del todo clara.  Otro cosa, es la simplificación de las variables a tener en cuenta a la hora de hacer el proceso de data mining, puesto que habría que tener en cuenta otros aspectos relativos al cliente, al receptor, ... Review_2: El artículo trata de un proceso de data mining orientado a describir agrupamientos para el análisis de lavados de activos en el rubro bancario. Utiliza como referencia metodológica el proceso CRISP-DM y lo sigue con cierta dedicación.  En cuanto al fondo: detalla demasiados aspectos que guardan relación con la parte descriptiva del tema financiero y del banco en particular donde se circunscribe el desarrollo del trabajo. También enfatiza la obtención de la vista minable que está bien, pero descuida la generación del modelo data mining, específicamente no muestra el modelo de clustering, tampoco los niveles de cobertura y confianza en cada regala de cada clúster, no realiza un análisis estadístico acerca de los patrones y tampoco se observa un validación del modelo y patrones obtenidos. Esto último es la mayor debilidad del trabajo.  En referencia a la forma: hay muchos errores de ortografía y redacción, excesivo el largo de algunos párrafos y redacción de algunos tópicos que se debieran resumir, también redacta en cuarta persona y en algunas partes en tiempo futuro, debiera estandarizar la redacción a 3era persona y tiempo presente, salvo en las conclusiones que puede ocupar tiempo pasado. Excede el nro. de páginas establecidas como máximo. Finalmente, presenta poca bibliografía (sólo 4) y además no las referencias en ningún lado.  Es un artículo que puede ser aceptado pero requiere un re-ordenamiento profundo en cuanto a la forma, y fundamentalmente en relación al modelo de data mining, su análisis y exhaustiva evaluación, así como sus resultados. 

Output: accept


Input: Consider Input: Review_1: Presenta una búsqueda de respuesta a partir de una solicitud en un call center.  El trabajo está bien presentado, pero muy largo, y eso no permite ver bien lo que quieren aportar los autores. 


Output: accept