Norberto Manzanos wrote: >Hola Hernán > >Ya conocía tu trabajo, porque es un tema que me ha preocupado siempre >y sobre el que he trabajado y trabajo permanentemente. Me parece >excelente, lleno de aciertos aunque no estoy del todo de acuerdo con >algunas cosas. > > Gracias!
>Antes que nada te aclaro que el dominio en el que trabajo es bien >distinto del que planteás en el paper (el mundo de los negocios) y el >que daba como ejemplo Esteban. Se trata del mundo de los documentos. >Para abreviar, documento en el sentido de información contenida en un >determinado soporte. Un documento es producido en un momento del >tiempo, es datado de determinada forma, por eso mi preocupación por >este tema. > > Me parece que mas alla que nuestro dominio sea el financiero y el tuyo el de documentos, el dominio del "tiempo" puede ser tratado en si mismo, con caracteristicas esenciales que lo hacen valido para un modelo ortogonal al resto.... por supuesto que pueden haber algunas abstracciones mas utiles para el dominio financiero o documental, pero seria bueno tener un model del tiempo mas alla del resto de los dominios. Nosotros tratamos de hacer eso, aunque en el paper hicimos incapie que solo lo usamos en el dominio financiero. >Estoy totalmente de acuerdo en que no hay una única forma de resolver >estos problemas, aunque puede haber soluciones que permitan incorporar >dominios diversos. > Ups, justo lo que puse mas arriba. Cuando yo puse que no hay una unica o mejor manera de resolverlo no quise decir que no se pueda tener "la mejor manera" en la cual todos estamos de acuerdo, y con eso basta.... lo que quise decir es que lamentablemente no tenemos formalismos que nos permitan demostrar que es la "mejor manera".... pero eso no importa si todos estamos de acuerdo no? >No se si el mundo de los negocios y el mundo de los >documentos pueden compartir un concepto de datación común. Lo nuestro >no es la ontología sino la informática, aunque tampoco puedo asegurar >que sea imposible llegar a un modelo ontológico de propósito general >del cual la informática (la representación informática de entidades) >pueda hacer uso. > > Estoy de acuerdo que lo nuestro es la informatica, pero la informatica tiene que ver mucho con la ontologia como manera de organizacion del conocimiento que adquirimos al modelar los dominios de problema en los que trabajamos. Esto lo hablamos mucho con Maximo Prieto, el profesor de la UBA de objetos... el siempre hace incapie en que lo nuestro es mucho mas adquisicion y representacion de conocimiento que otra cosa, por lo tanto la ontologia juega un papel importante en este proceso.... no se, comento esto porque me parecio interesante lo que estas poniendo. >Hechas estas aclaraciones, te comento sobre el paper. >Estoy totalmente de acuerdo con la metáfora propuesta: "time entities >as points of the time line with different resolution". La crítica al >modelo planteado en Squeak 3.7 me parece bien en algunos aspectos: >Month no representa un mes, sino un mes en un año y la separación de >ambos conceptos me parece un acierto. Lo mismo vale para Week. > Hey!, gracias!, me pones muy contento con esto que escribiste. >Pero >hay un tema polémico que es la invalidez de la comparación y de >operaciones entre entidades distintas. Yo ni siquiera estoy de acuerdo >con la opción de entregar un "unknown". Me parece perfectamente >aceptable realizar una comparación entre una datación con resolución >de años, contra otra de resolución de días. Pongo un ejemplo: tengo un >documento datado en 1745, no se el mes, nunca se supo. Otro datado el >día de ayer. Es evidente que el segundo es posterior al primero. >¿Acaso no comparamos Integers con Floats?. Tal vez no estoy >entendiendo algo del modelo. > > No, no estas entendiendo mal el modelo. Nosotros no permitimos comparar años con fechas porque se pueden llegar a producir inconsistencias. Lo que vos comentas es verdad, cualquier persona sabe que 1745 sucedio antes que hoy, de eso no hay duda, pero eso lo podemos hacer porque tenemos informacion contextual, los seres humanos nos basamos en el contexto para razonar, sino seria imposible que el lenguaje natural sea ambiguo por ejemplo. Mas alla de eso, el ejemplo que vos decis se puede resolver en un modelo formal como el nuestro. El problema surje cuando te preguntas, ¿es el año 2006 anterior a hoy?... ya fijate que hasta suena raro leerlo no?... y la verdad que para esta pregunta no hay respuesta... o sea el año 2006 no esta ni antes ni despues de hoy, en todo caso incluye a hoy, por lo tanto es ahi donde se ve el problema de comparar años con fechas. Es aca donde hay que tomar decisiones que haran que el modelo sea mas o menos consistente, mas o menos usable... nuestra decision fue que si se comparan estas cosas se genera un error porque no tiene sentido segun nuestra metafora. ¿Como resolver entonces el problema? Mi consejo es que en realidad para este ejemplo estamos necesitando otro concepto que no esta modelado (llamemoslo "Datacion" por ejemplo) que colaborara con "PointInTimes", pero que se encargara de resolver este tipo de problemas en base a lo que se acostumbra en el dominio de los documentos.... hasta quiza uno encuentre que no solo esto se hace en el dominio de los documentos y se pueda usar para otros, pero me parece que este tipo de problemas tienen que estar manejados por otros objetos... la idea de mantener el modelo de fechas lo mas minimal y puro posible permite luego agregar "arriba" otros modelos para manejar las particularidades. Nosotros tenemos dentro de nuestro software conceptos particulares del tiempo que se relacionan con las finanzas, como por ejemplo "FechaDeVencimiento". Fijense que es una Fecha, pero no cualquiera, esta relacionada con el hecho de que algo se Vence, evento tipico de las finanzas... >Estoy utilizando a propósito la palabra "datación" porque desde el >punto de vista de mi dominio se trata de una abstracción independiente >de los conceptos Year, Month, etc. No me estoy refiriendo a un punto o >un rango en la línea de tiempo, sino al nombre que se le ha otorgado a >ese punto. (*) Pero me voy del tema. Sigo con el paper. >La idea de "Time line views" como colecciones de reglas me gusta >mucho; me parece "la" solución para el problema de los feriados, que >pueden depender de distintas cosas. > Gracias otra vez! >Al releerlo me surge una duda. >¿Admitiría el modelo un feriado como Pascua o (si es que vuelve) >Carnaval, que están basados en el almanaque lunar? > Si, el modelo de TimeLineFilter (lo llamamos asi ahora) lo admite puesto que lo unico que contiene son reglas... no sabe sobre que calendario estan expresadas esas reglas... pero esto que te comento es teorico porque no tenemos modelado el calendario lunar que es el que permite como vos decis calcular las pascuas o el carnaval, por ahora solo modelamos el calendario gregoriano. >Y otra más >¿admitiría el modelo la existencia de "leapDays"? Digo esto porque en >un sistema de datación histórica, hay que considerar que hay días que >no han existido, por la corrección de los almanaques juliano y >gregoriano. > Este problema no lo encaramos... En ese sentido a nuestro modelo de falta funcionalidad. Con lo que hicimos alcanza para el dominio financiero y seguro que para muchos otros dominios, pero hay que ponerle mas funcionaliad y eso estamos haciendo... (bueno, en realidad lo esta haciendo Maxi como parte de su tesis)... En esta version nos preocupamos mucho en tener todos los objetos necesarios como dia, dia de mes, mes de año, etc.. O sea, nos preocupamos mas por el modelado que por tener una funcionalidad completa... >Incluso hay un problema más grande aún, aunque ya sería >visto desde un sistema de conocimiento: una datación antigua se ubica >en la línea del tiempo en función de desde donde se dice, o de quien >lo dice. Por ejemplo, Rusia adoptó el calendario Gregoriano recién en >1917, China en 1949 (quién dice que el comunismo no es moderno?), si >no me equivoco, la Iglesia Ortodoxa nunca adoptó el Gregoriano y sigue >con el Juliano. (Estos datos los saqué de "Historia del Calendario", >de David Ewing Duncan, Emecé, 1999, un libro muy recomendable). > > Esto que estas comentando fortalece aun mas la idea de que necesitas nuevos objetos para tratar estas situaciones. Con las abstracciones que nosotros creamos no alcanza. Ahora necesitas modelar el hecho del "punto en el tiempo segun un punto de vista", lo cual es algo muy interesante pero excede segun mi criterio al dominio del tiempo en si mismo... >Sigo con el paper. >Los objetos "endOfTime" y "beginningOfTime" son un gran hallazgo y me >gusta mucho la explicación "el mero hecho de que los pensemos".Me >parece un punto de unión entre una visión "naturalista", en el sentido >de partir de los datos de la realidad, lo que nos parece "natural" y >una visión matemática, formal, pues si se postula una linea numérica, >debe postularse el infinito. > > Gracias otra vez!! nos estas llenando de alagos!... en serio, es bueno tener feedback, gracias. >Pero también surge un problema que es clave a la hora de modelar: >cuándo es lícito acudir al "sentido común", cuándo a lo "natural", >cuándo a lo formal. ¿Vale acudir a lo que a uno le convenga en cada >situación? No lo digo como crítica, me lo pregunto realmente porque no >tengo respuesta. > Humm, es un buen punto. Mi manera de verlo es esta. Nosotros no vivimos en un mundo formal (o por lo menos aun no lo podemos formalizar por completo) por lo tanto es muy importante las observaciones que hagamos del mundo que nos rodea para crear un modelo sobre el mismo (que es nuestra funcion como programadores)... esto mismo hacen los fisicos, observan la realidad "fisica" y crean modelo sobre ella... por lo tanto creo que la misma pregunta que vos te hiciste la podriamos llevar al plano de la fisica y ahi veriamos que si, es licito puesto que de eso se trata!... el sentido comun es lo que permitio a varios fisicos llegar a los modelos que llegaron que luego se pudiron validar por observacion... Asi que yo creo que lo nuestro es mucho de sentido comun, de observacion, de entender todo lo que se esta relacionando en la realiad para luego a partir de ello llegar a un modelo de objetos que trate de reflejar esa realidad... por eso me gusta mucho Test Driven Development, por que yo hago la analogia de los test con "observaciones de la realidad", y si uno lo piensa asi, empieza a cerrar esta idea de que el desarrollo de software es adquisicion de conocimiento y generacion de un modelo de ese conocimiento. >Y justamente porque me surge una duda ontológica con >respecto a ciertos conceptos: Year y Day son conceptos "naturales", >son construcciones que tienen un correlato con un fenómeno natural >observable. Lo mismo valdría para LunarMonth o LunarYear. Month, Week, >Hour (y Decade, Millenium, etc) en cambio son sólo construcciones. > > Estoy de acuerdo, son construcciones humanas, pero ¿que importa?, tambien hay que modelarlas, lo mismo para el dinero, para la suma (aunque es mas discutible si es natural o una construccion humana), etc. O sea, no solo hay que modelar lo que es "natural", entendiendo por natural aquello que nos entrega la naturaleza sin ningun tipo de intervencion humana, tambien hay que modelar lo que el hombre genera, piensa, conceptualiza, etc. De hecho, las clases son un buen ejemplo de ello... >Bueno, no doy la lata más con divagaciones bizantinas, espero que todo >esto sirva de algo. > > A mi me encanto, mas alla de los alagos que de vuelta te agradezo, me parecio muy interesante tu mail y espero no haberlos aburrido con la respuesta. Un abrazo, Hernan. >Saludos >Norberto > > >(*) Si no entendí mal, esta distinción estaría reificada en las clases >GregorianDate y RelativeGregorianDate. > > La idea de RelativeGregororianDate tiene que ver con el filtro de linea de tiempo actualmente, no con la nocion de quien esta observando esa fecha, pero habria que ver, quiza se puede generalizar.... >> > > > --~--~---------~--~----~------------~-------~--~----~ Ha recibido este mensaje porque está suscrito a Grupos de Google "clubSmalltalk" grupo. Si quiere publicar en este grupo, mande un correo electrónico a [email protected] Para anular la suscripción a este grupo, envíe un mensaje a [EMAIL PROTECTED] Para visualizar más opciones, visite este grupo enhttp://groups.google.com/group/clubSmalltalk -~----------~----~----~----~------~----~------~--~---
