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. 
Output: reject