CONTEXTA Propuesta de Arquitectura

1. CONTEXTAPropuesta de Arquitectura Pablo Inostroza Valdera 21 de mayo de 2008

2. ADVERTENCIALas opiniones vertidas en esta presentación son de exclusiva responsabilidad de quien las emite, osea, yo

3. Tabla de contenidos • Una sencilla misión • Me demoro un par de horas… • Consideraciones sobre Contexta • El GRAN problema de fondo • Lo que teníamos • Ideas sueltas • Decisiones • Arquitectura de Contexta • Pasos a seguir

4. Una sencilla misión • Misión de esta semana: mostrar ciertas entidades específicas en el Explorador Patrimonial (usando templates de Marcelo) • Si queda tiempo, pensar en facetas • Fácil, ¿no?

5. Me demoro un par de horas… • “Obvio, soy sansano” • Pablo Inostroza • Realidad • Aproximadamente 16 horas de trabajo, sin conseguir ninguno de los dos objetivos • Hipótesis • Me titulé por suerte, ó • Algo pasa en nuestro querido proyecto

6. Consideraciones sobre Contexta • Tecnologías recientes (GWT, RDF y sus herramientas) • Incrementa tiempos de desarrollo • Falta de comunicación del equipo • Uno de los motivos (no nos exculpa por completo): Nunca ha habido un marco claro sobre la tecnología que desarrollamos • Entendemos el problema (trilogía artefacto-representación-circunstancia), pero no hemos acordado una *arquitectura* clara • Ejemplo concreto: MA, PI y CY ocuparon tres modelos de conexión con el datastore, distintos entre sí (lo que dificultó la integración)

7. El GRAN problema de fondo • Sólo entendemos a grandes rasgos lo que tenemos que hacer • Hay ambigüedades en las definiciones de más bajo nivel • Esto genera ISLAS de código (cito a MA) • Faltan definiciones arquitecturales • No hay responsables claros por conjunto de componentes o por área de desarrollo • Las tareas se asignan ad-hoc

8. Lo que concebimos la reunión pasada

9. Ideas “sueltas” • Aún el “mono” anterior, es demasiado genérico • Consideraciones que determinarán arquitectura • Diferenciación entre lo social v/s lo semántico • Preguntas con templates • Facetas como preguntas SPARQL + jerarquías • Ontology Manager pendiente • Visualización de recursos utilizando templates

10. Refinando las “ideas sueltas”: Hacia una arquitectura coherente de Contexta

11. Componentes Web Social • CY debió codificar un Servicio de Tags utilizando un framework RDF (Jena) • Esto fue la aproximación usada en Tutelkán • Resumiendo, este componente hace lo siguiente: Beans de Taggings Servicio de Tagging RDF Base RDF

12. Componentes Web Semántica • Por su parte, MA codificó el Servicio de Recomendaciones utilizando un componente Java preexistente (TASTE) Contexta Beans Servicio de Recomm TASTE Beans TASTE RDF Base

13. Web Social v/s Web Semántica • Luego de divagar por cuál de estos dos enfoques es mejor, planteamos: • Metáfora: “Pastelero a tus pasteles” • Usar para tareas sociales y estadísticas, componentes especializados, como TASTE • Utilizar RDF (y desarrollar sobre dicha tecnología) para manejar los artefactos y sus circunstancias • Se puede ver como estas dos funcionalidades son ortogonales

14. Preguntas con plantillas • Habíamos pensado en un componente para obtener “qué esta relacionado” con un ítem • En el fondo esto es una pregunta SPARQL parametrizada y que entrega una respuesta específica • ¿Es necesario crear un componente por cada uno de estos casos? • Idea de solución: Componente “Query Manager”

15. Preguntas con plantillas • Idea del Query Manager Pregunta con Parámetros e id Respuesta específica Query Manager Traduce el requerimiento expresado en la pregunta, en una consulta SPARQL que delega a Contexta Templates SPARQL Contexta

16. Presentación con plantillas • El componente “Resource Viewer” permite convertir la data original RDF referente a un recurso en algo mostrable al usuario final • La idea es asociar el tipo de recurso a mostrar (ej: Personas o Artefactos) a una transformación particular • Se pensó en excerpt

17. Presentación con plantillas • Puede convertirse a XHTML o cualquier formato (ej: RSS con nuevos ítems de CONTEXTA) • ¿Dónde estarán las plantillas para visualizar? • OpenAnzo, mediante MOJO, las deja en el cliente web (usando AJAX) • Podemos tener el “formateador de RDF” como cliente de los servicios de provisión de data de Contexta

18. Facetas • Vemos las facetas como una jerarquía referente a determinado criterio (no necesariamente asociada a un tesauro), donde cada uno de sus componentes se asocia a una pregunta SPARQL

19. Facetas • Ejemplo: Tiempo • Siglo XX • Primer Cuarto • Segundo Cuarto • Tercer Cuarto • Cuarto Cuart SELECT ?uri WHERE {?uri isadg:hasDate ?d FILTER (?d>01-011900 && ?d<31-12-2000) }

20. Facetas • Ejemplo: Geografía • VIII Región • Provincia de Ñuble • Provincia de Concepción • Concepción • Talcahuano SELECT ?uri WHERE {?uri rdf:type geo:SpatialThing. ?uri geo:typeId geo:ADMIN_1 ?uri geo:isContainedBy <http://sws.geonames.org/1323> } La info de geografía se encuentra en geonames, y hay un dump que debería bajarse a CONTEXTA

21. Ontology Manager • Este componente no lo requeriremos por ahora, es decir, asumiremos que no haremos tratamiento ontológico en CONTEXTA • Más adelante, visualizamos aplicaciones para hacer plantillas, que permitirían presentar datos relevantes a cierto dominio (en este caso debería haber un manejador de ontologías, ya que son el metamodelo de los datos a mostrar)

22. Decisiones • Se debe tomar varias decisiones respecto a la arquitectura, por ej: • Jena vs Anzo • Componentes RDF v/s enfoque híbrido • Uso de ontologías en capa inferior o superior • Templates a nivel de cliente (Anzo) o servidor • Simplificando, las alternativas de arquitectura son 2n, donde n es el número de decisiones • Decidir no es fácil => Hay que apostar a una combinación

23. Decisiones • Sin embargo, en algún momento hay que arriesgarse • Con Marcelo hemos conversado los puntos planteados y exponemos nuestras decisiones (discutibles ahora, por cierto)

24. Decisiones • Componentes sociales se tratarán de implementar utilizando frameworks existentes • Componentes “semánticos” se harán en base a Anzo • Template-oriented development • Para construcción de preguntas, visualización de recursos y facetas

25. Arquitectura

26. Propuesta de línea de trabajo

27. Pasos a seguir • Componentes a desarrollar • Contexta-Anzo Dataservice • Tags • Recomendador • Query Manager • Resource Viewer • Facets Generator

28. Pasos a seguir • Definición de “jefes de área” • Semántica • Construcción de Contexta Data Service y canalización de requerimientos semánticos de otros componentes [PI] • Auditoría [PI] • Ingesta [VC] • Query Manager [PI y ¿?] • Resource Viewer [PI y ¿?] • Facets Generator [?] • Social • Tagging [CY] • Recomendaciones [MA]

29. Pasos a seguir • Definición del próximo Milestone de resultados • ¿Qué componentes y qué funcionalidad de cada uno de ellos tendremos para dicho hito? • Se definirán componentes servidores (a mi juicio los más relevantes) y clientes • Quienes desarrollen componentes clientes trabajaran codo a codo con el diseñador (al parecer Rodrigo Vera)

30. Pasos a seguir • Definición del próximo Milestone de resultados • Cada uno se asignará una serie de tareas para lograr que el o los componentes a su cargo funcionen • Estas tareas se subirán como tickets a TRAC • Para la fecha del Milestone,se podrá ver el grado de avance de cada tarea

31. Pasos a seguir • En el caso de los componentes de servicio (como taggings, recomendaciones, contaxta data service), se publicará la interfaz que cada desarrollador propone en la wiki de TRAC • En dicho sitio se hablará también de la arquitectura genérica

32. Pasos a seguir • Estructura de la Wiki: • Contexta • Breve descripción • Arquitectura • Componentes • Componente 1 • Descripción • Link hacia página con interfaz • …

33. Sobre Contexta como proyecto • La imagen corporativa da identidad y seriedad a un proyecto • Ya que es muy probable que Rodrigo Vera trabaje con nosotros, propongo que en forma URGENTE se le solicite al menos un logotipo e isotipo de CONTEXTA • (y así reemplazo el feo logo con que se inició esta presentación)

34. That’s all folks!!! ¿Preguntas, discusiones, tomates? Apostaría que sí…