Post on 23-Jan-2016
CONTEXTAPropuesta de Arquitectura
Pablo Inostroza Valdera
21 de mayo de 2008
ADVERTENCIALas opiniones vertidas en esta presentación son de exclusiva
responsabilidad de quien las emite, osea, yo
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
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?
Me demoro un par de horas…
“Obvio, soy sansano”Pablo Inostroza
RealidadAproximadamente 16 horas de trabajo, sin
conseguir ninguno de los dos objetivos Hipótesis
Me titulé por suerte, óAlgo pasa en nuestro querido proyecto
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)
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
Lo que concebimos la reunión pasada
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
Refinando las “ideas sueltas”: Hacia una arquitectura coherente de Contexta
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:
Servicio de Tagging
Base RDF
RDF
Beans de Taggings
Componentes Web Semántica
Por su parte, MA codificó el Servicio de Recomendaciones utilizando un componente Java preexistente (TASTE)
TASTE
Base
RDF
Servicio de Recomm
TASTE Beans
Contexta Beans
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
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”
Preguntas con plantillas
Idea del Query Manager
QueryManager
Respuesta específicaPregunta conParámetros e id
SPARQL
Contexta
Traduce el requerimiento
expresado en la pregunta, en una consulta SPARQL
que delega a Contexta
Templates
Templates
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
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
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
Facetas
Ejemplo: TiempoSiglo XX
Primer Cuarto Segundo Cuarto Tercer Cuarto Cuarto Cuart
SELECT ?uriWHERE {?uri isadg:hasDate ?dFILTER (?d>01-011900 && ?d<31-12-2000)}
Facetas
Ejemplo: GeografíaVIII Región
Provincia de Ñuble Provincia de Concepción
Concepción Talcahuano
SELECT ?uriWHERE {?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
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)
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
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)
Decisiones
Componentes sociales se tratarán de implementar utilizando frameworks existentes
Componentes “semánticos” se harán en base a Anzo
Template-oriented developmentPara construcción de preguntas, visualización
de recursos y facetas
Arquitectura
Server
RDF DataStore
Anzo
ContextaDataService
RDB
TASTE
ContextaRecommendations
RDB
TaggingComponent ¿?
ContextaTags
Sparql Queries /
URI’s
RDF URI’s /Tags Beans
URI’s /Recomm.
Beans
ContextaRecomm.
Beans
Contexta QueryManager
Contexta ResourceViewer
Contexta FacetsGenerator
HTTP / JMS
HTTP / JMS
Heritage Explorer
Propuesta de línea de trabajo
Pasos a seguir
Componentes a desarrollarContexta-Anzo DataserviceTagsRecomendadorQuery ManagerResource ViewerFacets Generator
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]
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)
Pasos a seguir
Definición del próximo Milestone de resultadosCada 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 TRACPara la fecha del Milestone,se podrá ver el
grado de avance de cada tarea
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
Pasos a seguir
Estructura de la Wiki:Contexta
Breve descripción Arquitectura Componentes
Componente 1 Descripción Link hacia página con interfaz
…
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)
That’s all folks!!!
¿Preguntas, discusiones, tomates?
Apostaría que sí…