Backend de un portal de datos e información sobre la Tierra

Notas del editor

• #2: Dar las gracias al tribunal y a los asistentes Presentar el título del proyecto Presentarme a mi y a Labra
• #3: CONTEXTUALIZAR El TFG forma parte de un proyecto mayor llamado “Rebuilding IFAD’s Land Portal” en el que se pretende renovar el portal landportal.info Participaron: IFAD (agencia perteneciente a la ONU) como cliente y propietario del actual landportal.info. Tras la renovación del portal pasará a ser propiedad del Land Portal Partnership SBC4D como director del proyecto Grupo WESO (del que formamos parte) como desarrollador del proyecto
• #4: MÁS CONTEXTO Dijimos que el proyecto pretende renovar “landportal.info”, vamos a dar algunas cifras: “landportal.info” fue creado en marzo de 2011 En el año 2013 contaba con unos 1000 usuarios registrados En el año 2012 tuvo 70.000 visitantes únicos y unas 10.000 visitas mensuales 70 organizaciones
• #5: OBJETIVOS Ya hemos hablado sobre el antiguo “landportal.info”, pero ¿qué queremos conseguir con su renovación? Construir un portal de LOD: Colaborando con múltiples fuentes de datos independientes (las veremos posteriormente) Aportando visualizaciones (no sólo datos brutos) para facilitar su interpretación Fomentando la participación y el intercambio de ideas entre los usuarios Incluyendo una búsqueda unificada que facilite encontrar información Soportando internacionalización para democratizar el acceso a la información
• #6: OBJETIVOS Como dijo Tim Davies (coordinador del grupo de investigación de datos abiertos en la Web Foundation) en “Land Portal Strategy”…
• #7: ESTADO DEL ARTE ¿Es Land Portal único o existe algo similar? Algunos portales sólo proporcionan datos en bruto, lo que requiere un tratamiento previo para poder interpretarlos. Tampoco permiten participar a los usuarios. Enseñar “data.gov” y pasar a la siguiente
• #8: … seguimos de la anterior Enseñar “data.gov.uk” y pasar a la siguiente
• #9: … seguimos de la anterior. Otros proporcionan visualizaciones que facilitan la interpretación de datos, pero no permiten participar a los usuarios ni cuentan con un API para desarrolladores. Enseñar “landmatrix.org” y pasar a la siguiente
• #10: … seguimos de la anterior Una tercera variante son portales que permiten la participación de los usuarios pero no cuentan con las capacidades de un portal de datos. Enseñar “antiguo landportal.info” y pasar a la siguiente
• #11: COMO FUNCIONA Como hemos visto anteriormente, los objetivos del nuevo Land Portal son ambiciosos. ¿Cómo los consigue? DISEÑO MODULAR CON DIVISION DE RESPONSABILIDADES En primer lugar los datos que se utilizan provienen de diferentes fuentes de datos independientes (OMS, BANCO MUNDIAL, FONDO INTERNACIONAL DESARROLLO AGRICOLA, etc). Para introducir los datos en el portal hemos creado un Punto de Entrada (receiver / Alfred) para poder controlar cómo se incluyen los nuevos datos (programado en PYTHON) PROBLEMA: las diferentes fuentes de datos tienen formatos diferentes: json, xml, csv, Excel, apis, etc. SOLUCIÓN: como decía David Wheeler (universidad de Cambridge) “Todos los problemas en computación pueden resolverse añadiendo un nivel de indirección”. Hemos creado los importadores que transforman los formatos de cada fuente de datos a un formato único antes de enviarlos al punto de entrada de datos El receiver está diseñado para soportar distintos servicios de exportación de datos (RDF, SQL, CKAN con api) Apache redirige a los usuarios hacia los diferentes componentes de forma transparente Los datos enlazados se pueden visualizar con WESBY (además de con un SPARQL endpoint), un producto creado por WESO originalmente como parte del proyecto WebIndex 2013 en el que yo forme parte de sus últimas fases de desarrollo. Está escrito en SCALA Las visualizaciones de datos se ofrecen con WESCOUNTRY Una API para desarrolladores Un gestor de contenidos (DRUPAL) que actúa como principal punto de acceso a los usuarios, está escrito en PHP. El gestor de contenidos se comunica con APACHE SOLR para proporcionar un sistema de búsqueda unificado
• #12: COMO FUNCIONA Como hemos visto anteriormente, los objetivos del nuevo Land Portal son ambiciosos. ¿Cómo los consigue? DISEÑO MODULAR CON DIVISION DE RESPONSABILIDADES En primer lugar los datos que se utilizan provienen de diferentes fuentes de datos independientes (OMS, BANCO MUNDIAL, FONDO INTERNACIONAL DESARROLLO AGRICOLA, etc). Para introducir los datos en el portal hemos creado un Punto de Entrada (receiver / Alfred) para poder controlar cómo se incluyen los nuevos datos (programado en PYTHON) PROBLEMA: las diferentes fuentes de datos tienen formatos diferentes: json, xml, csv, Excel, apis, etc. SOLUCIÓN: como decía David Wheeler (universidad de Cambridge) “Todos los problemas en computación pueden resolverse añadiendo un nivel de indirección”. Hemos creado los importadores que transforman los formatos de cada fuente de datos a un formato único antes de enviarlos al punto de entrada de datos El receiver está diseñado para soportar distintos servicios de exportación de datos (RDF, SQL, CKAN con api) Apache redirige a los usuarios hacia los diferentes componentes de forma transparente Los datos enlazados se pueden visualizar con WESBY (además de con un SPARQL endpoint), un producto creado por WESO originalmente como parte del proyecto WebIndex 2013 en el que yo forme parte de sus últimas fases de desarrollo. Está escrito en SCALA Las visualizaciones de datos se ofrecen con WESCOUNTRY Una API para desarrolladores Un gestor de contenidos (DRUPAL) que actúa como principal punto de acceso a los usuarios, está escrito en PHP. El gestor de contenidos se comunica con APACHE SOLR para proporcionar un sistema de búsqueda unificado
• #13: TECNOLOGÍAS El número de componentes que forman parte del nuevo Land Portal es grande, también lo es el número de tecnologías utilizadas: PHP -> módulos del CMS y API interna para las visualizaciones Drupal -> Gestor de contenidos Python -> lenguaje para le punto de entrada de datos Flask -> microframework de desarrollo web para el punto de entrada de datos MySQL -> como base de datos relacional desde la que se ofrecen los datos al usuario HTML + CSS + BOOTSTRAP-> para la interfaz de usuario
• #14: ZONA SOCIAL Como se ha mencionado anteriormente el nuevo Land Portal tendrá dos orientaciones principales: por un lado será un portal de LOD y por otro una plataforma social en la que los usuarios intercambien información y opiniones. Hablaremos primero de ésta zona social, que recibe el nombre de “landdebate”
• #15: El “landdebate” utiliza las capacidades de Drupal la realizar la gestión de usuarios, contenidos y comentarios. Los tipos de contenido, así como el aspecto visual de ésta sección han sido totalmente personalizados. Cabe destacar que la interfaz gráfica está internacionalizada en tres idiomas y puede ser extendida con tantos idiomas como se deseen. Todos los contenidos de esta sección se integran con el sistema de búsqueda para facilitar su descubrimiento.
• #16: Aquí podemos ver el diagrama con el modelo de datos del “landdebate”: Tenemos tres roles de usuario además de los usuarios anónimos: Anónimos -> consumidores de información, sólo pueden ver los contenidos creados Registrados -> consumidores y creadores. Pueden crear debates, eventos, noticias y además comentar en las entradas del blog y los debates Acceso al API -> además de consumidores y creadores también son difusores de información Administradores -> tienen capacidades de administración y además pueden crear organizaciones y entradas del blog
• #17: Ahora haremos una demostración del “landdebate”. Entraré en la web del Land Portal real, si tienen sus tablets, smartphones o ordenadores portátiles les invito a acceder también a ustedes y navegar por el portal. Podrán acceder en la dirección “landportal.weso.es”
• #18: Tras haber visto la zona social, hablaremos ahora de la zona de datos, que recibe el nombre de “landbook”
• #19: El “landbook” está formado por: El punto de entrada de datos Una API interna que proporciona los datos necesarios para la generación visualizaciones Al igual que sucedió con el “landdebate” el “landbook” también está integrado en Drupal. Puesto que Drupal usa el patrón arquitectónico PAC, para integrar las vistas de ésta sección hemos creado un pequeño framework que nos permite trabajar de una forma similar al patrón MVC. El “landbook” también soporta internacionalización. La internacionalización está soportada tanto a nivel de interfaces como a nivel de datos Por último, el “landbook” también está integrado con la búsqueda unificada
• #20: Las peticiones llegan al controlador, quien va llamando a los diferentes servicios Los servicios utilizan el modelo de datos común para exportarlo El parser transforma los datos que llegan en la petición al modelo de datos común. Para ello utiliza un XML Schema definido El servicio de SQL utiliza un ORM (“sqlalchemy”) para la persistencia El servicio de RDF envía los datos a Virtuoso El servicio de CKAN utilza el API de CKAN para enviar los conjuntos de datos junto con mentainformación sobre su contenido
• #21: ¿CÓMO FUNCIONA EL MECANISMO DE SELECCIÓN DE PLANTILLAS E INTERNACIONALIZACIÓN? El ‘hook_menú’ es automáticamente invocado por Drupal cuando un usuario accede a una de las rutas asociadas. Las rutas se especifican en un fichero JSON de configuración. Selecciona el idioma escogido por el usuario y devuelve sus etiquetas traducidas. Busca el modelo por convenio de nombres. La clase del modelo se instancia utilizando reflectividad y posteriormente se llama a su método ‘get’ para que nos devuelva los datos con los que se rellenará la vista. El modelo realiza consultas a la base de datos y las cachea para futuras peticiones. Mustache localiza la plantilla adecuada y la renderiza con las etiquetas traducidas y los datos del modelo. En caso de que exista un fichero Javascript, se utilizará como controlador de la vista. Todo este sistema utiliza un mecanismo de “convención sobre configuración” para buscar idiomas, plantillas, modelos y Javascript. Los idiomas se puden añadir directamente al directorio adecuado y están automáticamente disponibles en el portal. Al igual que los modelos, las vistas y los Javascript se buscan por convenio de nombres dependiendo de la ruta a la que acceda el usuario.
• #22: A continuación veremos una demostración del “landbook”, cabe recordar que las vistas de esta parte no han sido desarrolladas como parte del TFG, pero utilizan el framework MVC explicado anteriormente, las visualizaciones utilizan el API interno. Al igual que antes, les invito a que entren con sus dispositivos.
• #23: Pruebas de integración durante todo el desarrollo y apoyadas por un servidor de integración continua (Travis CI) Pruebas de rendimiento usando profiling cuando se acabó el punto de entrada de datos Pruebas de aceptación con el sistema probado por el cliente durante una semana y media (originalmente una semana) Las pruebas pueden verse detalladas en el capítulo 7 de la documentación.
• #24: Mencionar que el Hackatón iba a tener lugar en el Open Knowledge Festival 2014 (Berlín) pero se celebró entre el 15 y el 17 de julio y el proyecto aún no había terminado.
• #27: Opiniones extraídas de https://basecamp.com/2037036/projects/4324721/topics
• #28: Opiniones extraídas de https://basecamp.com/2037036/projects/4324721/topics
• #29: Opiniones extraídas de https://basecamp.com/2037036/projects/4324721/topics
• #30: Las peticiones llegan al controlador, quien va llamando a los diferentes servicios Los servicios utilizan el modelo de datos común para exportarlo El parser transforma los datos que llegan en la petición al modelo de datos común. Para ello utiliza un XML Schema definido El servicio de SQL utiliza un ORM (“sqlalchemy”) para la persistencia El servicio de RDF envía los datos a Virtuoso El servicio de CKAN utilza el API de CKAN para enviar los conjuntos de datos junto con mentainformación sobre su contenido
• #31: Cuenta con un fichero en el que se declaran las rutas El modelo de cada ruta devuelve los datos necesarios para rellenar la vista Los datos se cachean en la primera petición Los modelos se buscan por convenio de nombres y usando reflectividad “mustache” nos permitió rellenar las plantillas con los datos devueltos por el modelo Si el modelo no se encuentra se carga la vista de error 404
• #32: Aquí podemos ver el diagrama con el modelo de datos del “landdebate”: Tenemos tres roles de usuario además de los usuarios anónimos: Anónimos -> consumidores de información, sólo pueden ver los contenidos creados Registrados -> consumidores y creadores. Pueden crear debates, eventos, noticias y además comentar en las entradas del blog y los debates Acceso al API -> además de consumidores y creadores también son difusores de información Administradores -> tienen capacidades de administración y además pueden crear organizaciones y entradas del blog
• #33: Aquí podemos ver el diagrama con el modelo de datos del “landdebate”: Tenemos tres roles de usuario además de los usuarios anónimos: Anónimos -> consumidores de información, sólo pueden ver los contenidos creados Registrados -> consumidores y creadores. Pueden crear debates, eventos, noticias y además comentar en las entradas del blog y los debates Acceso al API -> además de consumidores y creadores también son difusores de información Administradores -> tienen capacidades de administración y además pueden crear organizaciones y entradas del blog
• #34: Aquí podemos ver el diagrama con el modelo de datos del “landdebate”: Tenemos tres roles de usuario además de los usuarios anónimos: Anónimos -> consumidores de información, sólo pueden ver los contenidos creados Registrados -> consumidores y creadores. Pueden crear debates, eventos, noticias y además comentar en las entradas del blog y los debates Acceso al API -> además de consumidores y creadores también son difusores de información Administradores -> tienen capacidades de administración y además pueden crear organizaciones y entradas del blog
• #35: Aquí podemos ver el diagrama con el modelo de datos del “landdebate”: Tenemos tres roles de usuario además de los usuarios anónimos: Anónimos -> consumidores de información, sólo pueden ver los contenidos creados Registrados -> consumidores y creadores. Pueden crear debates, eventos, noticias y además comentar en las entradas del blog y los debates Acceso al API -> además de consumidores y creadores también son difusores de información Administradores -> tienen capacidades de administración y además pueden crear organizaciones y entradas del blog