niryuu/sni-each-converted huggingface dataset:
Review_1: El paper describe el contexto actual del uso de tecnologías disponibles para controlar de manera automática la dosificación de macronutrientes en los tratados de cultivos sin suelo.  El trabajo es pertinente en su definición y desarrollo. Sin embargo, el título induce a una expectativa que no se logra satisfacer en el documento. El paper ofrece una discusión sobre el estado del arte en tecnología para la problemática abordada, sin embargo, no ofrece un framework comparativo, criterios de selección, o sugerencia sobre buenas prácticas.  Como primer acercamiento al área de investigación es pertinente, sin embargo, algo más de trabajo propio debe ser añadido al paper. Review_2: El artículo realiza un estudio bibliográfico interesante sobre la tecnología IA aplicada en el campo de la fertirrigación y dosificación de nutrientes para cultivos sin suelo. No establece ni describe el diseño de una solución sobre un caso de estudio, y sólo se queda en el estudio preliminar. Por lo que el título “Diseño y Construcción de un Sistema Automático….”  No corresponde, y tendría que orientarse a lo que describe, es decir algo así como: “Análisis y estudio de los sistemas automáticos…”  Es un artículo tipo survey interesante pero se contradice con el título y la introducción, las conclusiones también no son acorde a este tipo de trabajos, debieran ser más ad-hoc con variables comparativas. Review_3: El título del trabajo induce al lector a la espera de encontrarse con el diseño e implementación de un sistema de control de regadío, sin embargo a medida que se profundiza en la lectura del documento esto se ve cada vez más lejano, ya que el autor nos propone una revisión de diversos resultados de trabajos realizados por terceros en una especie de recopilación de información referente al tema, para finalmente plantear desde su punto de vista cuales de estos resultados pudiesen ser considerados de interés dependiendo del tipo de cultivo.  Es necesario modificar el nombre del artículo ya que induce a confusión al lector, pues al finalizar de revisar el documento no se ha obtenido como resultado el diseño ni menos la construcción del sistema de regadío, sólo se han obtenido alternativas a considerar dependiendo de diversos factores. Tal vez es necesario enfocarse en un tipo de cultivo específico para realizar en detalle el diseño y la implementación del sistema de regadío con la finalidad de realizar pruebas que validen el trabajo realizado. 
Output: accept
Review_1: Los comentarios aparecen en el archivo adjunto Review_2: El  trabajo "Liderazgo en adopción de TI en PYMEs ¿Sólo el involucramiento del propietario importa?" explora a través de la metodología IA la relación entre involucramiento del propietario y el éxito de la TI en PYME. Si bien es un buen trabajo, el texto puede ser mejorado en algunos aspectos de forma y fondo: 1.	Los autores deben declarar el objetivo del estudio para facilitar la lectura del trabajo. 2.	Lamentablemente los autores cometen un error importante al colocar a  D&M como modelo de aceptación a nivel individual ("Otros modelos de aceptación a nivel individual incluyen: el modelo de DeLone y McLean (D&M) [5]"). De hecho, a partir de ese error la redacción del texto confunde dimensiones del éxito del uso de sistemas de información (el modelo D&M) con modelos de adopción de tecnologías de información (TAM y sucesores). Los autores deben revisar D&M y ver las implicaciones para su trabajo de la correcta interpretación de este modelo. 3.	Asociado a lo anterior, ¿que entienden los autores por éxito del uso de sistemas de información? deben explicarlo, ¿los beneficios individuales y los beneficios organizaciones son parte de ellos?,  ¿es posible que otras dimensiones del éxito del uso de sistemas de información, como la calidad de la información y la calidad de servicio de la función informática, sean variables importantes para explorar en los dos proyectos estudiados? 
Output: accept
Review_1: No concuerdo con lo que está escrito en el segundo parágrafo de la introducción. Una solución para un problema NP completo, por ejemplo el cajero viajante, puede ser programada de forma simple... el problema radica en que la respuesta del programa puede tardar mucho. Para contornar esto se buscan heurísticas o meta-heurísticas que tal vez no encuentren la respuesta ideal pero si un buena respuesta.  En la página 3, observe que Pa no es un elemento de A y si un subconjunto de A o más precisamente un subconjunto de A-{a}. En ese mismo parágrafo habla de "dos tipos de restricciones" pero la segunda no está explícitamente colocada. Al final del parágrafo sería interesante decir que "o sea, ai pertenece a Paj". La frase está muy larga: 16 líneas!  No queda claro en las figuras 1 y 2 la restricción de que "la suma de la cantidad de tipo de recurso k utilizado en el período t, Rk(t), no debe exceder de Rk".  En la formulación matemática  del RCPSP no está claro que significaría por ejemplo que Fj tome el valor 5 y el significado de pj y de A(t).  Faltó una comparación estadística de cuan buena es la calidad de la solución encontrada con el algoritmo propuesto de otras soluciones o al menos una comparación que muestre que tan distante está la solución encontrada de la ideal.  Las referencias parecen no tener un orden lógico (alfabético o orden de citación). Review_2: El trabajo es DEMASIADO preliminar: no existen experimentos y por tanto sin resultados ni análisis.  El trabajo solo se enfoca en realizar una discusión de métodos de optimización para el problema en cuestión. Posteriormente, solo define formalismos conocidos y genéricos para el problema.   El paper es MUY débil, requiere aún MUCHO trabajo para ser un manuscrito con alguna relevancia! Review_3: El trabajo presenta una aproximación para la programación de proyectos mediante algoritmo de colonia de abejas. El trabajo, aun cuando tiene una buena redacción, es carente de la aplicación del algoritmo, no presenta un ejemplo o varios de aplicación.  Muestra la metodología, define bien el problema, pero no muestra un ejemplo de aplicación del algoritmo. En la figura 2 muestra una posible solución a un ejemplo planteado, pero no indica si es a través del algoritmo propuesto u otro método.  No queda claro el aporte de la investigación, ni los resultados. 
Output: reject
Review_1: El trabajo pretende ofrecer una visión del uso de herramientas EVA en los diferentes entornos de asignaturas de enseñanza superior (presenciales, no presenciales y semipresenciales). La idea del paper es clara pero me cuesta trabajo encontrar la justificación de investigación del mismo. Los resultados que se obtienen son bastante segados y la propuesta no está definida como un experimento claro. Creo que hubiese sido interesante un mayor rigor a la hora de plantearlo. Hay además algunos aspectos, como por ejemplo, el hecho de la lista de evas seleccionadas que no se justifica, ¿de dónde se ha obtenido esa lista? ¿es cerrada?.  Por todo ello, abogo por no aceptar este trabajo. Review_2: El paper está bien escrito y de fácil lectura.  Se ajusta al formato del evento.  Estado del arte bien planteado y revisado.  El rechazo débil es por qué no está de acuerdo a los tópicos de interés de los trabajos de INFONOR, ver listado en [Link]#areas-interes  El paper debería ser presentado en un evento de Educación en Ingeniería. Para los cual se sugiere que los resultados obtenidos sean comparables con asignaturas sin tutorías y analizar los resultados de aprendizajes que logran los alumnos en grupos de control y experimental. 
Output: reject
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. 
Output: accept
Review_1: Se presentan los siguientes problemas de forma:  - Figura 1: el texto de la figura no es legible y además se encuentra deformado. - Figura 2: no representa la problemática expuesta en el trabajo, además no se encuentra referenciada. - Ortografía: ".. del uso de La tecnologia NFC ..", debe ser: ".. del uso de la tecnología NFC ..". - Faltan puntos a parte. - Ortografía: ".. aplicaciones com relacion al uso .." debe ser: ".. aplicaciones con relación al ..". - Tabla 1: Título incorrecto y tabla cortaba en su final. - Cambio de tamaño de letra después de la tabla 1 - Tabla 2: Texto deformado. - A lo largo del texto no posee referencias a las afirmaciones: "es muy difícil intervenir una comunicación NFC". - Las etapas del proceso de transacción deben estar enumeradas. - Las tablas se encuentran mal numeradas. - Las páginas no se encuentran numeradas. - La descripción de indicadores (sección 7) no aporta al trabajo propuesto.   Problemas de fondo:  - No presenta una solución formal al pago vía tecnología NFC, a pesar que es el punto central del trabajo. - Las interfaces gráficas presentadas no se encuentran definidas en conformidad con las normas gráficas de aplicaciones móviles. - Las conclusiones no arrojan luz sobre la problemáticas planteada.  El trabajo desarrollado no es claro sobre la problemática planteada, debería incluir un análisis más detallado de tecnologías ya implementadas: UberTaxi, etc. Review_2: El documento refleja que el equipo de trabajo cuenta con cierto dominio en la tecnología necesaria para alcanzar los objetivos planteados, sin embargo no está bien redactado, carece de sustento en trabajos previos, la aplicación no está bien descrita. Se recomienda también cuidar la redacción, concretar las ideas y cuidar la estructura en el documento. Se recomienda además una revisión profunda buscando la síntesis y profundizar en los detalle de la propuesta software que describen, y también se recomienda aplicar una metodología, describirla y describir la validación de la herramienta descrita (generar por ejemplo casos de prueba y describir la validación). 
Output: reject
Review_1: El artículo presentado, describe  cómo modelar un sistema multiagente de acuerdo a la metodología orientada a agentes “GAIA” para modelar la trazabilidad de requisitos.  La propuesta de GAIA  para modelar la trazabilidad de los requisitos mediante Sistemas multiagente parece ser novedosa.  La presentación del artículo es bastante confusa, el documento presenta algunos errores ortográficos, de redacción y  de estructuración, se referencia a tablas que son figuras, se presentan tablas no referenciadas, no existe la figura 6, el ítem “resultados” debe ser cambiado o descrito en otro lugar del documento. Conclusiones insuficientes. Review_2: - El artículo describe varios enfoques para elaborar requisitos, y aplica uno de ellos (GAIA) a la construcción de sistemas multi-agentes (MAS).  - La Introducción es larguísima y cubre muchos temas; debería ser dividida en varias secciones, y dejar en Introducción sólo el contexto general y descripción del resto del artículo. - No hay un ejemplo para ilustrar la técnica, que es descrita en 1,5 páginas, siendo lo esencial de la contribución. - No hay validación de tipo alguno. Review_3: Se propone la utilización de la metodología GAIA para la trazabilidad a los requisitos, el enfoque propuesto se basa en la capacidad social de los agentes para procesar conocimiento, percibir los cambios del entorno y comunicación. Se trata de una tarea compleja, pues en el desarrollo de software se emplean gran variedad de modelos y diagramas que facilitan la representación de del conocimiento, estos artefactos se modifican en el tiempo. Estos cambios vienen principalmente desde el usuario.  Se requiere profundizar en la aplicación práctica de la propuesta para evaluar de mejor manera el aporte científico y práctico. 
Output: accept
Review_1: El artículo describe los conceptos de minería de datos y los pasos que un proceso KDD lleva a cabo en general, y esto último lo asocia a redes sociales y en particular a Facebook presentándolos como una adaptación propia, lo cual carece de fundamento y lógica. Por ejemplo, menciona las redes sociales donde los usuarios manifiestan gustos, sentimientos y otros estados, lo cual por lo general se presentan en texto, y por el contrario no señala nada respecto al tratamiento de texto para determinar la frecuencia de palabras y con esto lograr determinar los temas de conversación de un grupo de usuarios en la red. También describe algunas técnicas de minería de datos y mezcla la minería del web, quizás tratando de combinar diferentes métodos de minería que sería lo más lógico si se quiere abarcar diferentes aspectos de las redes sociales, es decir contenidos de texto se debiera utilizar el proceso KDT y no KDD, para el manejo de asociaciones o vínculos minería de la estructura de la web, etc. En la página 9 señala que utilizó la técnica de representación icónica para visualizar resultados, sin embargo no hay evidencias de esta experimentación en todo el trabajo. Finalmente en la conclusiones habla de una guía desarrollada la cual no se explícita en ninguna parte del artículo. También se debe señalar que tiene algunos errores de redacción, repetición de artículos y palabras. Review_2: Es un artículo bien escrito que da una idea de cómo usar técnicas de mineración de datos en redes sociales como el Facebook. Es un tema actual e intrigante. Pero sentí falta de cosas más concretas, o sea una implementación concreta de una de las técnicas mencionadas aplicadas al facebook o a otra red social.  La frase "el cual puede convertir datos cuyo almacenamiento es innecesario." en la página 3 parese inconclusa. Convertir en que? Review_3: El artículo describe algunos aspectos generales de la aplicación de minería de datos a redes sociales.  La revisión de información no es completa y dista mucho de ser considerada como el estado del arte del tema.  Sugiero primero revisar artículos de revistas indexadas en el tema, identificar un problema de investigación concreto, donde se pueda realizar un aporte en el tema, y plantear una propuesta de investigación. 
Output: reject
Review_1: Este artículo propone un conjunto de medidas de cuantificación basadas en la triangulación de Delaunay de características de las huellas dactilares como principios para un esquema de indexación.  El trabajo se expone mayoritariamente claro y las propuestas y resultados son interesantes para el congreso. Cabe hacer notar los siguientes aspectos negativos o que no quedan claros en el trabajo:  - Cuidado con mezclar títulos en inglés y contenido en español (revisar) - Revisar la redacción de la conclusión   "siendo esta casa vez menor a medida" - De los resultados mostrados, sólo la tabla 2 realiza presenta un resultado comparativo con otras soluciones, por lo que otros gráficos deberían también incluirse en forma "comparativa" - No queda claro la eficiencia de la propuesta ni el tamaño de la bd, más bien parece pequeña en relación a la cantidad de huellas que se espera que un sistema real maneje. Esto dificulta el apreciar y encontrar justificación a los 45 segundos presentados cuando el sistema se "estabiliza" - Se echa de menos que ante la definición de cualquier tipo de índice, no haya un desarrollo más elaborado de la complejidad computacional, estructura de datos y ambiente de pruebas utilizado para tomar los tiempos. 
Output: accept
Review_1: En este trabajo se realiza una propuesta exploratoria sobre un perfil de adecuación de técnicas de educción de requisitos de software. El trabajo es una extensión de un trabajo previo.  Se recomienda mejorar algunos aspectos de este manuscrito como son: -Describir a más detalle el trabajo previo en el que se basa este escrito y mencionar las diferencias y contenido nuevo. -Consistencia entre los términos requisitos y requerimientos, en la pág. 3 se emplea el término requerimientos. -En la medida de lo posible mantener términos en castellano. -Añadir acento en "solo" siempre y cuando se refiera a "únicamente". -Corregir "Lo" por "Los" final de pág. 4, después de ref. 15., añadir acento a "comparara", en misma pág., corregir "cuatros" final pág. 6. -Corregir alineación de texto en primeros párrafos de ambas columnas en pág. 10, el primer párrafo de la segunda columna debería estar en la primera columna. Review_2: Artículo enfocado en las técnicas de educción de requisitos. Como comentario general, en las frases del tipo sujeto+verbo, no es necesario poner una coma después del sujeto (por ej., en la sección de introducción "la educación de requisitos de software, es aquella ...", en la de background "la ingeniería del software, es una disciplina .."). Respecto a la Tabla 2, sería conveniente que los autores pusieran las filas de la tabla en el mismo orden en que los enumeran. Un par de cuestiones me surgen: ¿Cómo se construye la situación contextual de un proyecto? (candado) Aunque me imagino que será un proceso similar, ¿Cómo se construye el perfil de adecuación de las técnicas? (llave) Consiste en poner el gráfico de la técnica por dimensión en forma plana? Si pudieran aclarar con alguna frase. Por ejemplo, indicar que las dimensiones tienen un número (indicadlo en la Tabla 4 por ejemplo), para luego ver claramente los gráficos de la Figura 4. Lo mismo para los factores y la Figura 3. 
Output: accept
Review_1: El trabajo presenta una evaluación de tres sistemas software de videoconferencia, la evaluación se realiza tomando como referencia algunos modelos de calidad existentes.  Si bien el trabajo resulta de interés para la comunidad, éste requiere de mayores mejoras. Se recomienda mejorar los siguientes aspectos:  -Para evitar posibles sesgos en la evaluación se recomienda utilizar varios evaluadores no solamente uno. -No está claramente justificado el porqué de la elección de los tres sistemas evaluados habiendo más en el mercado. -Falta mejorar el estilo de redacción, por ejemplo se observan inconsistencias en el uso de referencias, se emplea tanto formato numérico como por nombres (pag. 7). La tabla 2 puede colocarse como apéndice, en los sumarios no suelen colocarse referencias. Review_2: El artículo presenta una propuesta de un modelo para evaluar la calidad de productos de software para video conferencias basado en open source. Si bien es cierto es tema es de interés y la propuesta tiene elementos de interés, el artículo presenta algunas oportunidades de mejora que deberían ser abordadas antes de su aceptación.  Contenido: - El apartado de "Antecedentes" provee muy poca información para ser un apartado como tal. Se recomienda explicar brevemente el sustento teórico que entregan las investigaciones base utilizadas.  - En varias ocasiones se menciona que también se definieron métricas, pero en ningún momento se entrega alguna referencia respecto a dónde pueden ser vistas en detalles si el lector está interesado. Además, en la página 5 se indica que son 73 métricas, luego en la pág. 7 se dice que son 72 y en las conclusiones sólo se resaltan 68.  - Sugiero que la sección "Algoritmo para aplicar el Modelo de Calidad..." sea apoyado por algún diagrama para representar algoritmos, por ejemplo, un diagrama de flujo o de actividades, ya que el texto es algo confuso y no permite entender de manera fácil el algoritmo propuesto.  - No queda claro cómo se determinaron los valores de la Tabla 4.  - No queda claro cómo se aplicó el modelo, ¿cómo se calculan los porcentajes de la Tabla 5?  - La tablas 2 y 3 son muy extensas lo cual provoca que el lector se pierda un poco del contexto analizado. Sugiero separarlas en diferentes tablas (separar la tabla 2 por categoría y la tabla 3 por características)  Formato:  - En el apartado "Metodología" dice "...el objeto se define...." creo que debe decir "...el objetivo se define..."  - El nombre de la figura 1 presenta un error. Dice "Caliad" en lugar de "Calidad"  - El abstract en inglés no incorpora todo lo que dice en su versión en español (no se indica nada de las métricas)  - El formato de referencias bibliográficas indica que se numera según el orden de aparición, y en el artículo se parte por la referencia 6, luego del 6 salta al 13.  - Hay artículos mencionados en la sección de referencias que nunca son referenciadas en el texto del artículo.  - En la pág. 7 hay un error en el formato de las referencias, debe ser formato numerado, y aquí aparece "(Basili et. al., 2001) 
Output: reject
Review_1: This is a developed application to support information with sounds. Although it is a particular situation to aid with the use of sounds, it does not presents new knowledge in any areas or has any type of empirical validation; one from the user point of view might add some value. Review_2: El artículo presenta una prueba de concepto respecto a la asociación de sonido a un índice financiero (RSI).  El artículo tiene una estructura adecuada, presenta los conceptos, trabajo relacionado y la propuesta de "sonificación" en forma clara. No obstante, es escueto en la descripción de la implementación, los resultados obtenidos y su análisis.  Algunos errores gramaticales menores:  - pag. 1, columna derecha, primer párrafo. "Is in this context" - pag. 3, columna derecha, segund párrafo. "minimums and maximums frequencies..."; "to void damaging..."  Algunos aspectos a mejorar:  No queda claro cuál podría ser la ventaja respecto a otras posibles formas de asociar sonido al RSI.  Se requiere mayor explicación y detalle respecto a la implementación.  El trabajo carece de una parte empírica donde se pueda juzgar o estimar el valor del esquema propuesto frente a otras posibles opciones. Esto se explica por su carácter de prueba de concepto, pero no se menciona esto como trabajo futuro. 
Output: accept
Review_1: Interesante propuesta de desarrollo de un vídeo juego para tratar el deterioro cognitivo del adulto mayor. Se ve como una propuesta novedosa, y que abre un nuevo campo de desarrollo de video juegos. Desde este sentido se considera un aporte al congreso.  Sin embargo, lo que el paper presenta es todavía una propuesta en desarrollo, por lo que todavía no se puede validar el enfoque del proyecto, lo cual se presenta como trabajo futuro. Por lo mismo, tampoco queda muy claro como encajaría el uso del video juego dentro de una estrategia mayor del tratamiento del deterioro mental de los adultos mayores, dentro de la cual el juego debería ser una herramienta más.  Por último, hay algunas afirmaciones que no están debidamente respaldadas por evidencias en el paper, tales como: "cuando hay tareas complejas es mucho más difícil para el joven que para el adulto mayor, ya que el adulto mayor tiene la experiencia mientras que el entrenamiento es sólo práctico" 
Output: accept
Review_1: Un muy buen artículo. Solo sugiero lo siguiente:  Las tablas en la sección de resultados deben ser explicadas.  Las tablas solo contienen el menor, mayor y media entre esos dos valores. Sería interesante considerar también la media general y la desviación estándar.  En las tablas 4, 5 y 6 solo algunas líneas contienen un valor destacado, las veces el mayor de la línea y otras el menor... Explicar mejor el significado de esas marcaciones en todas las tablas.  La referencia [12] comienza con "and" y no con el nombre del primer  autor (de echo parece que están con problemas también el resto de los autores).  La referencia [22] es la única que no usa iniciales para el nombre del autor. Review_2: No existen hipótesis en la investigación!  No se aprecia la contribución del trabajo  Varios problemas conceptuales en la introducción (ej. "SVM son clasificadores no-lineales"  .. son lineales.. lo que pasa que se pueden extender a problemas no separables linealmente mapeando a dimensiones mayores usando funciones de kernel!! , etc ).  No es claro el objetivo de los experimentos. Que se está tratando de probar? que se puede decir de los resultados (accuracy, etc) obtenidos? porque los resultados son diferentes (mejores/peores, etc) que los otros métodos que se mencionan? Review_3: Este trabajo muestra la clasificación de género basado en descriptores locales, compara los resultados utilizando un modelo basado en apariencia y modelos SIFT y SURF. El trabajo muestra con claridad el procedimiento llevado a cabo y los resultados, tiene una adecuada bibliografía y es novedoso en cuanto a la aplicación de los algoritmos en clasificación de género. Tiene una buena redacción, existiendo algunos pequeños errores de ortografía. 
Output: accept
Review_1: Problemas de forma identificados:  - Figura 7 no es clara en su contenido. - Figura 5 y 6 no aportan al trabajo desarrollado. - El proceso de transacción debería estar numerado. - Cuadro debería ser Tabla, además la tabla 2, 3 y 4 no son legibles. Se deberían re-escribir. - Página 3 el texto de la palabra Samsung no es del mismo tipo de fuente. - Figura 8 no tiene título. - Se debe corregir y mejorar la ortografía (conclusiones).   Problemas de fondo:  - El apartado 3.1.2 no se encuentra relacionado directamente con el problemática planteada. - La descripción de las arquitecturas y modalidades de utilización de NFC no aporta a la solución expuesta. - En la sección 4.1 se hace mención a la máquina virtual Dalvik, sin embargo, desde la versión de Android Lollipop hacia arriba, se utiliza ART y no Dalvik. - La tabla 6 no aporta el trabajo desarrollado. - El trabajo desarrollado utiliza 8 de 11 páginas en introducción y tecnologías, sin embargo, sólo se utiliza 1 página para mostrar las evidencias. - Se plantean algunos indicadores, sin embargo, no se da evidencia de los valores obtenidos. - Las figuras 10, 11 y 12 muestran capturas de la aplicación?, sin embargo, no se indican en detalle la forma de aplicación de las tecnologías en Android. - Falta evidencias de la aplicación descrita, en particular desde al área de la ingeniería de software. Review_2: Este trabajo hace una presentación de trabajos relacionados con el control de acceso de personas a determinadas instalaciones. Describe algunas tecnologías que se pueden emplear para implementar este control. Sin embargo, se queda en una propuesta que trata de adaptar soluciones a un problema local. Falta más desarrollo de modelos y sustento teórico para presentar una solución original, que aporte al avance en esta área. OBSERVACIONES DE FORMA: 1) Indicar las referencias usadas en el texto con corchetes []. 2) Mejorar la redacción del texto, uso de conectivos, prenombres, acentos ortográficos, puntos, comas, etc. Por ejemplo: "El alumno, simplemente al acercar el móvil al libro, recibirá en su terminal la información Correspondiente al texto sin ninguna intervención."  3) El título: "1. Otras Secciones." Review_3: El formato simplemente pésimo, la redacción deja también bastante que desear, las figuras borrosas, tablas escaneadas de algún lugar sin referencia. El contenido no existe. Este debe ser uno de los artículos más malos que he visto en mi vida, 
Output: reject
Review_1: Validación cualitativa de UTAUT, Evidencias desde un estudio de investigación acción es un  trabajo que aporta un interesante ejemplo de investigación acción. Sin embargo, existen algunas posibilidades de mejoras. Primero, sugiero a los autores mejorar la conceptualización de "comportamiento de uso" pasando de un "adopto/no adopto" (dicotómico), a un "nivel de uso" para probar H4 y H5. Por otra parte, y en relación a las conclusiones, creo que si bien en UTAUT 2 FC es un antecedente de BI, esto es sólo en el contexto de tecnologías de consumo, y no creo que sea una comparación útil en el contexto e-learning, sugiero buscar referencias en ese contexto. Finalmente, creo que los autores deberían profundizar seriamente en las diferencias del contenido de los cursos que adoptaron y  los que no lo hicieron, ¿es posible que este contenido condicione el  uso de herramientas de evaluaciones electrónicas? Se sabe que algunos contenidos son más fácil de evaluar con herramientas electrónicas. 
Output: accept
Review_1: El artículo presenta el diseño de un prototipo que implementa un sistema para la adquisición de datos mediante dispositivos móviles inalámbricos, aplicado a la minería, específicamente en la monitorización de material particulado. Resulta interesante la aplicación de la tecnología móvil a un problema concreto de la industria minera chilena, además el artículo describe de forma muy clara la problemática y el prototipo propuesto.  El artículo resulta novedoso ya que se plantea el uso de la computación (procesamiento de de datos) y de las tecnologías de dispositivos móviles aplicadas a un problema concreto de la industria minera chilena.  El problema, la tecnología presentada (BUG) y el prototipo propuesto están descritos de forma clara.  Resulta relevante la aplicación  de tecnologías computacionales móviles actuales en sectores industriales importantes del país.  El título principal y el resumen deben estar escritos en español y en inglés (sólo vienen en español). Además, el artículo presenta una lista de 29 referencias, pero sólo hace referencia  a una (la primera de la lista). Incluso aparece en las Referencias PCFactory, y no queda muy  claro el porqué. Review_2: Considera el uso de tecnologías móviles para incorporar en la medición de material particulado que existe en el interior de una mina. Será interesante ver las ventajas y desventajas de esta aplicación con otras existentes.  Es un estudio solamente. Todavía no hay resultados. 
Output: accept
Review_1: El artículo describe un caso de innovación empresarial que apoya los procesos de aprendizaje organizacional. El principal mérito del caso es que se ha logrado un impacto muy significativo con una inversión modesta de recursos. Adicionalmente se enfatiza al conocimiento como un elemento estratégico para la organización, el cual requiere acciones concretas de gestión y asignación de recursos. Finalmente, se debe destacar una redacción impecable y amena del caso. Review_2: El artículo describe una interesante aplicación en el ámbito de la capacitación y que entrega herramientas de gran utilidad para la empresa en el mejoramiento de los procesos del aprendizaje de los trabajadores. El artículo identifica las ventajas que este tipo de plataformas entrega a las empresas que las utilizan.  El artículo no define adecuadamente el propósito del mismo y establece en su inicio que este objetivo es "dar a conocer", lo cual no es un propósito adecuado para estas investigaciones.  El artículo se denomina plataforma para la gestión del conocimiento, sin embargo el artículo no define el marco teórico adecuado a esta temática. (no hay autores relevantes en la gestión del conocimiento y los procesos asociados a esta).  El artículo no justifica adecuadamente en la literatura la relevancia de estas plataformas en los proceso de aprendizaje y experiencias internacionales en el tema  No existe un apartado que presente la metodología de investigación seleccionada por los autores, más bien los autores describen una aplicación y sus componentes. Falta claramente el diseño de la investigación.  Las conclusiones del artículo se relacionan con la importancia de estas plataformas para la empresa, pero no se enfocan en los resultados obtenidos en la empresa que implementa, no hay recomendaciones para futuros estudios y no existe reconocimiento de las limitaciones del mismo 
Output: accept
Review_1: RESUMEN. El trabajo propone un modelo para evaluar la calidad de un software orientado a agentes. Básicamente, el modelo considera tres propiedades para evaluar su calidad: habilidad social, autonomía y pro-actividad.  Para evaluar estas propiedades, el autor descompone estas propiedades en varias sub-propiedades medibles. El autor evalúa este modelo a través de un caso estudio: un sistema bancario.  Comentarios Generales: De manera notaría, la estructura del documento tiene los aspectos necesarios para ser considerado un artículo científico. La contribución del artículo pareciese ser relevante.  Dicho esto, este trabajo carece de algunos puntos que (para mí) es importante abordar:  * El autor menciona que no hay modelo para evaluar la calidad del software de agente, y el propone uno. Su propuesta es una adaptación de ISO/IEC, sin embargo, el autor no justifica por qué es la apropiada.  * Con respecto al punto anterior, el párrafo 1 de la introducción dice que no hay modelo de que mida la calidad del software. Luego, el párrafo 2 menciona que hay algunos trabajos acerca de esto. El autor debería clarificar su contribución.  * El autor menciona que se desarrolló un software para este trabajo, sin embargo, este trabajo aparece como otra publicación más (y de otro autor). Si es el software mencionado no es parte de las contribuciones del trabajo, por favor, eliminar estas frases.  Otros comentarios:  * En la sección del caso de estudio no es tan fácil entenderla. Por ejemplo, figuras 2, 5 y 7 no se entiende a que se refiere sus siglas (ej. AMS). Supongo que corresponden a los sub-propiedades.  * Se recomienda intercambiar la sección 3 por la sección 2. Es decir, primero explicar que es un agente y luego hablar del trabajo relacionado.  * No me queda claro si es "agente software" o "agente de software". Incluso, el autor también confunde esta terminología (primera oración de la sección 4). Review_2: El trabajo presenta una propuesta interesante para evaluar el paradigma de desarrollo de software orientado a agentes y aunque es un trabajo en curso tiene buenas bases.  Se sugiere volver a redactar el Resumen de manera que sea más comprensible, utilizando de nuevo los sustantivos cuando sea necesario y con una estructura menos rígida. 
Output: accept
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
Review_1: El paper cuenta conlas secciones Introducción, Análisis Teórico, Resultados, y Conclusiones.  El paper está mal estructurado. En la sección Análisis Teórico se entremezclan conceptos básicos y aspectos metodológicos. La sección Resultados de un caso de estudio que en ningún lugar es definido. Posteriormente, se efectúa un análisis en palabras de resultados sobre una situación experimental tampoco descrita al detalle que garantice una replicabilidad experimental mínima. Finalmente, la sección Agradecimientos es altamente informal.  La redacción no sigue el canon usual de papers (redacción en tercera persona), sino que se presenta en primera persona. Se requiere mejorar sustancialmente el orden y la presentación de cada sección.  En resumen, el paper sugiere la idea de que la implementación de sistemas instrumentados de seguridad es vital para mejorar la seguridad y calidad de procesos en la industria. Sin embargo, no se proponen modelos, experiencias, resultados empíricos concretos u otro equivalente. No existen motivos reales para proponer la aceptación de este trabajo. Review_2: El paper presenta una investigación enfocada a evaluar el impacto de los sistemas instrumentados de seguridad en los procesos a los cuales se aplican.  La cantidad de referencias es pobre, considerando la naturaleza de la investigación. Es especialmente escaso el uso de referencias en la sección introductoria. También, la introducción no deja muy claro el aporte de la investigación ni la metodología utilizada, ambas cosas deberían ser parte de esta sección de manera concisa.  Se debe evitar el uso de primera persona plural en la redacción (ej., 3er párrafo de la sección "análisis teórico").  Colocar las referencias dentro del párrafo, no fuera (ej., párrafo "Medidas de seguridad", "... iniciado. [7]", debería ser "... iniciado [7].". Esto se repite en otras partes del documento.  Error de escritura en primer párrafo de 3era página.  Formato de referencias inconsistente (segundo párrafo en "Riesgo remanente aceptado"). También mal uso de puntuación (Primer párrafo de 4ta página).  Sobre los resultados, estos no son claros. La pregunta de investigación está mal o ambiguamente planteada. En base a esto, es imposible entender el aporte o el enfoque planteado. Esto sumado al escaso marco teórico entregado, no se justifica la relevancia de la investigación presentada.  Las conclusiones no hacen referencia a ningún aspecto de investigación ni trabajo futuro.  Se debe revisar el formato de las referencias.  Por todos los motivos expuestos anteriormente, el trabajo no tiene la calidad suficiente para ser aceptado. 
Output: reject
Review_1: En su forma, tiene algunos problemas, por ejemplo en la página 5, en la descripción del laboratorio implementado, se describe, la estructura propuesta con seis cámaras para localizar los robots en el campo durante un juego de futbol, señalando que esto es mostrado anteriormente y aparece [9], donde figura ni referencia existen. Por otro lado, en medio de las referencias bibliográficas, aparece la figura 14, que no es referenciada en el documento.  En su contenido, sobre el 50% del artículo está dedicado, al análisis de técnicas de captura de posición y movimiento por triangulación de imágenes, tratadas reiteradamente en la literatura técnica y que no aporta valor desde el punto de vista científico. Es solo una recopilación bibliográfica de técnicas de visión. Por otro lado, la descripción de los resultados no son un aporte al tema del artículo que es el  uso de técnica de visión para la determinación de robots dedicados a futbol.  Finalmente creo que el autor del artículo fue muy poco riguroso al escribirlo, donde al menos debía haberlo revisado antes de enviarlo. Review_2: Muy buen artículo para comprender la ubicación espacial de objetos, con propósitos de control, en este caso aplicable a un conjunto de robot en un juego de futbol. Review_3: Me parece un artículo interesante de ser considerado, aunque el objetivo final del mismo es algo oscuro: "medir la posición de robot en un campo de futbol". En particular, no es claro si el trabajo se orienta a un objetivo posterior más ambicioso (múltiples robots, movimiento del equipo en tiempo real, y que hacer finalmente con estos datos???).  Por lo que puede deducirse, aunque no es explícitamente dicho, se hicieron mediciones de "un" robot "ubicándolo" en diferentes posiciones del campo, pero no con este moviéndose en tiempo real. Se presentan así resultados, que podrían haberse obtenido con otra configuración más clásica del área de visión computacional (el aporte del robot y el campo de futbol, al menos hasta ahora no tienen una relevancia fundamental en el trabajo desarrollado).  Finalmente, no me parece que los resultados obtenidos sean estrictamente novedosos, pero aun así puede ser una experiencia atractiva de ser conocida. 
Output: accept
Review_1: Resumen: Este trabajo describe una experiencia del uso de un lenguaje "gráfico" en una escuela.  Evaluación: El tópico del trabajo es interesante, sin embargo, a) la descripción del trabajo es débil y b) los resultados parecen no repetibles.  Por ejemplo para a), la descripción no muestra ninguna imagen de cómo funciona el lenguaje (recordar que es un lenguaje gráfico). Un ejemplo de scratch es fuertemente recomendable para introducir el lenguaje.  Por ejemplo para b), no hay una clara descripción de la configuración de los experimentos, los resultados que se quieren medir y tabla para apreciar fácilmente los resultados obtenidos.  Detalles menores: a) El comienzo del abstract es súper complejo de entender b) Un excesivo uso de "esto es" c) algunas faltas de ortografía como "preunta" d) Oraciones muy largas. Review_2: Fondo: - Se menciona de manera muy superficial el lenguaje a utilizar en forma posterior a Scratch, quizás no es necesario o se debe ahondar más en el tema. - El número de alumnos sobre el cual se aplicó el estudio es muy pequeño para obtener resultados concluyentes. - Sería deseable una comparación o estudio entre la utilización de Scratch y Alice (mencionado en el trabajo). - Concluir a partir del experimento que Scratch es una herramienta adecuada para la educación en Chile, sin incluir resultados con otros lenguajes es un poco apresurado. - Sería deseable mencionar que instituciones o trabajos relacionados con lenguajes para fomentar el pensamiento lógico se han realizado en Chile. No se menciona ninguno como referencia o en la bibliografía. - El ejercicio utilizado en el experimento es uno sólo, se deberían utilizar más si se desea objetivamente evaluar su utilización como lenguaje para mejorar el razonamiento lógico. - La primera cita proviene de un portal de noticias Colombiano y del 2006. Sería deseable una referencia más sólida y local asociada quizás a los lineamientos y planes de estudio del ministerio de educación.   Forma: - Se debe re-escribir el abstract: posee muchas palabras separadas por comas y la redacción incluye ideas desconectadas entre sí. - Se cita 8 veces la cita 7/8. Con la mitad de ellas queda clara la referencia. - ".. pero pocos aprender a programar .." debería ser: ".. pero pocos aprendeN a programar ..". - La cita 2 dice .. "Fundamentos de POgramacion".. debería ser: ".. Fundamentos de Programación". Review_3: El artículo presenta un interesante desarrollo de un caso, como una propuesta más de metodología de inicio para la didáctica de la lógica de programación. Las conclusiones presentadas no tienen mucho fundamento en términos del logro del objetivo de inducir de esta manera el razonamiento lógico. 
Output: accept
Review_1:  Review_2: Un muy buen trabajo, presenta integración de varias tecnologías de una forma clara y coherente  A pesar de que lo mencionan como trabajo futuro, se debería tener en cuenta el HL7 desde ya 
Output: accept
Review_1: El artículo presenta una evaluación de técnicas de algoritmos genéticos para la ingeniería inversa en línea de productos de software. La mayor parte del trabajo se enfoca en presentar y explicar detalladamente la Ingeniería de Líneas de Productos de Software (ILPS) y la aplicación de Ingeniería inversa sobre este paradigma. La explicación asociada a ILPS y a Ingeniería Reversa es detallada en la Introducción del artículo, incluso para ingeniería reversa se entregan más dos definiciones para el mismo concepto. Sin embargo, en la misma sección no se hace referencia alguna a Algoritmos Genéticos que también es parte de este trabajo.  En general el trabajo es interesante pero carece de un alto impacto innovador respecto a trabajos asociados a Algoritmos Genéticos.  En la sección de Resultado y Evaluación se muestra un detalle de Tablas de Resultados, sin embargo la discusión y explicación de resultados solo se entrega en 1 párrafo. Se esperaría una explicación más clara respecto al significado de cada una de las columnas de la tabla y resultados correspondientes.  En la sección de referencias hay 3 referencias [11], [12], [13] para establecer una definición, se esperaría tener mayor referencias a trabajos similares, quizás que se pudiera incluir una sección de Related Work.  Menores. -- En general se recomienda revisar la redacción de algunas frases. Solo como ejemplo recomiendo revisar la última frase del Resumen. Otro ejemplo es el párrafo de AGRADECIMIENTOS. -- En figura 2 no se visualiza correctamente la serie "Con LPS" en impresión Blanco/Negro -- En pág. 8 penúltimo párrafo hay un "." que es del párrafo anterior en una línea en blanco. -- La tabla 2 tiene un formato de Fuente más grande y al parecer de otro tipo al del resto del artículo. Review_2: El documento describe una forma de aplicar técnicas actuales de ingeniería informática al problema de líneas de productos de software. El documento está bien explicado, pero se considera necesario profundizar en los resultados y la evaluación. El trabajo descrito es interesante ya que aplica Algoritmos Genéticos a un problema concreto, pero carece de  impacto innovador en el dominio. Se recomienda revisar la redacción (en general) del documento. 
Output: accept
Review_1: -	No existen bases científicas explicitas en este trabajo y su aporte a la práctica es nulo. 
Output: reject
Review_1: - El artículo aborda un problema contingente y muy relevante, e incluye tanto un diagnóstico nacional de uso de buenas prácticas como una solución (buenas prácticas concretas). - El lenguaje es adecuado.  - El artículo se siente como la concatenación de tres artículos diferentes: (1) resultados de una encuesta, (2) buenas prácticas de seguridad, (3) incorporación de buenas prácticas. - El orden de las secciones sería mejor si refleja este orden (la versión revisada es #2, #1, #3). - El artículo no tiene validación de ningún tipo, ni siquiera por evaluación de expertos. Review_2: El artículo presenta recomendaciones prácticas para el desarrollo de software seguro. Se describen las mejores prácticas recomendadas para desarrollar software que sea proactivo ante los ataques, y se realiza un análisis de costos de estas prácticas en desarrollo de software. Todo basado en una revisión de prácticas propuestas en la bibliografía y su contraste con datos obtenidos de una encuesta en empresas. Finalmente se recomienda una guía.  Sería ideal aplicar la guía propuesta a empresas no involucradas en la encuesta que sirvió para originarla de modo de poder evaluar su efectividad en forma independiente. Review_3: - El tema es muy interesante y puede ser de mucha ayuda una guía para incorporar prácticas de seguridad. - La presentación (descripción, etapa y uso) de las 9 prácticas para el desarrollo de software seguro.  - El “estado real del desarrollo de software en Chile” (como lo indica en su paper) no se puede lograr con solamente 22 encuestas de un total de 50. - Presenta nueve tablas que corresponden a las prácticas para el desarrollo de software seguro, pero la guía presenta 10 prácticas. ¿explica por qué? - Sugiero mejorar la guía, el mayor aporte está en la secuencia de incorporación que propone.  Además, no debería explicar la práctica en Observaciones ni diferenciarla con otras prácticas en esa columna, sino que debería dar sugerencias de cómo aplicarla. - En el texto indica “Más adelante, se presentan además tres prácticas extras…” ¿cuáles son o no leí correctamente? - De acuerdo a formato, poner como mínimo 5 palabras clave. - Sugiero mencionar las prácticas antes de mostrar cada tabla. - Algunas referencias están incompletas, por ejemplo, falta año en referencia 17, falta año y tipo de evento en referencia 11, falta editorial en referencia 19 (¿es un libro?) - Algunos títulos llevan una coma dentro de las comillas, ejemplo, referencia 1 
Output: accept