Estudio de plataformas t Estudio de plataformas

Estudio de plataformas tecnológicas
tecnológicas
datos.gob.es
En colaboración con
Las opiniones recogidas en este documento no se
corresponden, necesariamente, con las de ninguno
de los organismos públicos participantes en esta
iniciativa.
Contenidos
I. Propuesta de trabajo. ...................................................................................................... 2
1
Objetivo. ........................................................................................................................ 2
2
Estudio de CMS............................................................................................................. 3
2.1 Aspectos valorados de los CMS ................................................................................. 4
2.1.1 Facilidad de instalación / administración ............................................................... 4
2.1.2 Facilidad de uso ................................................................................................... 4
2.1.3 Potencia gráfica y estructural ............................................................................... 4
2.1.4 Gestión de usuarios y workflows .......................................................................... 5
2.1.5 Funcionalidades Web 2.0 ..................................................................................... 5
2.1.6 Posibilidades de extensión e integración .............................................................. 5
2.1.7 Seguridad ............................................................................................................. 5
2.1.8 Soporte, tamaño de la comunidad ........................................................................ 6
2.1.9 Soporte nativo semántico (RDF, RDFa, …) .......................................................... 6
2.1.10 Plataforma .......................................................................................................... 6
2.2 Valoraciones de los CMS ........................................................................................... 7
2.2.1 Liferay .................................................................................................................. 7
2.2.2 Drupal ................................................................................................................... 8
2.2.3 Wordpress ............................................................................................................ 8
2.2.4 Joomla .................................................................................................................. 9
2.2.5 Plone .................................................................................................................... 9
2.3 Tabla comparativa de valoraciones .......................................................................... 10
2.4 CKAN ....................................................................................................................... 11
2.5 Conclusiones finales ................................................................................................ 12
3 Estudio de plataformas semánticas .......................................................................... 14
3.1 Necesidades funcionales semánticas del Portal OpenData Estatal .......................... 14
3.2 Comparación de servidores semánticos ................................................................... 15
3.2.1 Servidores semánticos nativos - Berlin SPARQL Benchmark (BSBM) ................ 15
3.2.1.1
Máquina utilizada para la realización de las pruebas ................................. 15
3.2.1.2
Descripción de las pruebas........................................................................ 16
3.2.1.3
4store ........................................................................................................ 16
3.2.1.4
BigData...................................................................................................... 16
3.2.1.5
BigOwlin .................................................................................................... 17
3.2.1.6
Virtuoso ..................................................................................................... 17
3.2.1.7
Gráfica resumen. ....................................................................................... 18
3.2.2 Aplicación propia desarrollada en Java .............................................................. 18
3.2.2.1
Máquina utilizada para la realización de las pruebas ................................. 18
3.2.2.2
Descripción de las pruebas........................................................................ 19
3.2.2.3
Java + Jena + Oracle Semantics ............................................................... 19
3.2.2.4
Java + Jena SDB + MySQL ....................................................................... 19
3.3 Conclusiones finales ................................................................................................ 19
4 Arquitectura propuesta............................................................................................... 20
1
I. Propuesta de trabajo.
1 Objetivo.
El objetivo de este documento es presentar un análisis comparativo de las diferentes tecnologías
disponibles como plataformas para el desarrollo del portal OpenData Estatal.
La plataforma a desarrollar tendrá dos partes bien definidas. Primeramente constará de un
sistema de gestión de contenidos web (CMS) que soportará la creación y gestión de las
páginas web del portal por un lado, y también el mantenimiento del propio catálogo, formado por
los conjuntos de datos publicados por el Portal OpenData Estatal. La primera parte del informe
valorará los mejores CMS disponibles actualmente y propondrá la selección de uno de ellos para
este proyecto.
Además, la plataforma implementada deberá contar con tecnología semántica que permita la
publicación de los metadatos del Catálogo en RDF1, así como la publicación de datos en RDF de
aquellos conjuntos de naturaleza semántica. Esta plataforma semántica deberá exponer los datos
siguiendo los principios de Linked Data2 y deberá implementar un punto SPARQL3. La segunda
parte del informe analiza las opciones tecnológicas disponibles que mejor se adecuan a las
necesidades del nuevo portal.
1
Resource Description Framework (RDF): http://www.w3.org/RDF/
2
Linked Data - Connect Distributed Data across the Web: http://linkeddata.org
3
SPARQL Query Language for RDF: http://www.w3.org/TR/rdf-sparql-query
2
2 Estudio de CMS
Existe una enorme variedad de gestores de contenidos web (CMS – Content Management
System) en el mercado. Para el objeto de este estudio se ha realizado un filtro previo y sólo se
han comparado los mejores gestores de contenido web a fecha de la realización del análisis.
De forma genérica, para la selección inicial de los candidatos se han tenido en cuenta dos
grandes criterios de selección:
•
OpenSource. El software libre no impone un coste de licencia, y cuenta con las grandes
ventajas del código abierto: flexibilidad, seguridad y rapidez en las tareas de desarrollo y
actualización.
•
Cuota de uso y relevancia. El uso de tecnologías con la mayor comunidad de usuarios
posible ofrece importantes ventajas: mayor soporte disponible, mayor número de módulos
de terceros desarrollados y probados por la comunidad, garantía de evolución de la
plataforma.
Atendiendo a los criterios generales mencionados se han seleccionado un grupo de cinco CMS
candidatos:
•
Liferay4
•
Drupal
•
Wordpress6
•
Joomla7
•
Plone8
5
En el resto del informe se describen las funcionalidades y características que se han comparado
atendiendo a las necesidades del nuevo portal. También se presenta un resumen de las virtudes y
las desventajas de cada uno de los CMS y una puntuación final en forma de tabla.
4
Liferay: http://www.liferay.com
5
Drupal: http://drupal.org
6
WordPress: http://wordpress.org
7
Joomla Spanish: http://www.joomlaspanish.org
8
Plone CMS: http://plone.org
3
2.1 Aspectos valorados de los CMS
Para la comparación de los diferentes gestores de contenido se han agrupado en una serie de
aspectos diferenciados el conjunto de las funcionalidades y características que tienen este tipo
de sistemas. A continuación se describen cada uno de estos aspectos y los puntos más
significativos que se han comparado.
2.1.1 Facilidad de instalación / administración
•
Facilidad con que se pueden encontrar un proveedor de servicios con soporte en sus
servidores para la plataforma tecnológica seleccionada. Costes de hosting.
•
Facilidad para la instalación y despliegue de un portal básico vacío.
•
Usabilidad de las vistas de administración.
•
Cantidad y calidad de la documentación de administración disponible.
•
Soporte visual para la gestión de módulos de terceros incluidos.
•
Soporte visual para la gestión de temas y estilos gráficos soportados.
•
Soporte para la actualización de la plataforma a una nueva versión.
2.1.2 Facilidad de uso
•
Inclusión de editores de texto enriquecido.
•
Facilidad de inclusión de imágenes y elementos multimedia embebidos en las
páginas.
•
Control de versiones sobre los contenidos creados.
•
Facilidad en la gestión de barras de menú, cabeceras y pies.
•
Soporte para la gestión de imágenes y documentos subidos al portal. Herramienta
para buscar y eliminar recursos que han sido subidos pero ya no son utilizados.
•
Usabilidad general de los controles y vistas.
2.1.3 Potencia gráfica y estructural
•
Inclusión de un sistema de gestión de temas gráficos. Facilidad en la administración
de los temas gráficos soportados.
•
Disponibilidad de repositorios externos con temas gráficos libres. Cantidad y calidad
de temas gráficos disponibles.
•
Flexibilidad para la creación de nuevos temas gráficos o para la modificación de los
existentes.
4
•
Posibilidad de incluir el máximo de características HTML y CSS disponibles en la
creación de un tema gráfico.
•
Facilidad y flexibilidad en la creación de estructuras jerárquicas complejas para los
contenidos de un portal.
•
Creación de nuevos tipos de contenido.
•
Disponibilidad de funcionalidades típicas ya implementadas: buscador de contenidos,
tipos de contenido más utilizados (noticias, eventos, etc.)
2.1.4 Gestión de usuarios y workflows
•
Gestión de usuarios, roles y permisos sobre tipos de contenido y secciones del portal.
•
Posibilidad de dividir las tareas de creación, modificación, revisión y publicación de
los contenidos.
•
Posibilidad y facilidad de creación de workflows entre diferentes roles con las fases de
publicación de contenidos.
2.1.5 Funcionalidades Web 2.0
•
Soporte para comentarios sobre los contenidos del portal. Posibilidad de configuración
para diferentes niveles de autenticación, permisos y moderación.
•
Soporte para la votación de contenidos del portal. Posibilidad de configuración para
diferentes niveles de autenticación y permisos.
•
Funcionalidad para la configuración y publicación de feeds de los contenidos del portal.
•
Soporte integrado para la creación de blogs.
2.1.6 Posibilidades de extensión e integración
•
Sistema par la creación de módulos que extiendan la funcionalidad básica del CMS.
•
Disponibilidad de herramientas de desarrollo específicas del CMS que facilitan la
creación de nuevos módulos y la extensión de las funcionalidades.
•
Facilidad de integración con otros sistemas: posibilidad de uso de diferentes sistemas
de persistencia; cohesión con diferentes sistemas de autenticación y autorización;
existencia de APIs para la conexión con otros sistemas mediante servicios web.
2.1.7
•
Seguridad
Volumen de problemas de seguridad y vulnerabilidades encontrados para el CMS y
registrados por entidades independientes.
5
•
La comunidad del CMS dispone de una metodología y plan precisos para el
descubrimiento y reparación de vulnerabilidades y problemas de seguridad.
2.1.8 Soporte, tamaño de la comunidad
•
Los fuentes del CMS han sido soportados por la comunidad como un paquete
opensource por un periodo de tiempo largo.
•
Cantidad de entidades y consultorías que dan soporte o basan sus servicios y
productos en el CMS.
•
Existencia de libros publicados de calidad sobre el uso del CMS.
•
La comunidad del CMS cuenta con foros dedicados para la resolución de problemas
específicos de los usuarios.
2.1.9 Soporte nativo semántico (RDF, RDFa, …)
•
Existencia de soporte nativo para la gestión de vocabularios y ontologías RDF.
Calidad del backoffice para realizar dicha gestión de vocabularios.
•
Existencia de funcionalidades nativas en el CMS para la asociación entre los contenidos
estructurados del portal y los vocabularios RDF gestionados. Posibilidad de asociar
cada tipo estructurado a una o varias clases RDF y mapear parte de los campos del tipo
estructurado a propiedades RDF.
•
Posibilidad de publicar las asociaciones RDF creadas en formatos semánticos:
•
Enriquecimiento de las páginas HTML de las instancias de contenidos
estructurados con RDFa9.
•
Posibilidad de publicación de la información semántica de los contenidos creados
mediante formatos específicos RDF: RDF/XML10, Turtle11, N312.
2.1.10
•
Plataforma
A priori el entorno de ejecución o lenguaje de programación de cada CMS no supone
una ventaja decisiva para ninguno de ellos. Sin embargo sí que se debe tener en cuenta
la orientación general que tienen cada una de las plataformas:
•
Java/JEE. Orientado a entornos “enterprise”. Java sobresale en utilidades y
librerías de soporte para funciones de interoperabilidad. Es un lenguaje
semicompilado lo que lo hace más rápido que lenguajes de script interpretados.
9
RDFa Primer - Bridging the Human and Data Webs: http://www.w3.org/TR/xhtml-rdfa-primer
10
RDF/XML Syntax Specification: http://www.w3.org/TR/rdf-syntax-grammar
11
Turtle - Terse RDF Triple Language: http://www.w3.org/TeamSubmission/turtle
12
Notation 3: http://www.w3.org/DesignIssues/Notation3.html
6
•
PHP. Muy orientado al desarrollo web. Tiene una cuerva de aprendizaje muy baja y
se alcanza una gran productividad con poco esfuerzo. Es un lenguaje de script
interpretado lo que lo hace algo más lento en ejecución que java.
•
Python. Orientado al desarrollo web. Es un lenguaje más moderno y mejor
diseñado que PHP, pero algo más complejo y difícil. Es un lenguaje de script
interpretado lo que lo hace algo más lento en ejecución que java.
2.2 Valoraciones de los CMS
A continuación se presenta una valoración resumida de las ventajas y desventajas de cada uno
de los CMS.
Hay que reseñar que dentro del amplio espectro existente de gestores de contenidos web, los
cinco preseleccionados forman parte del reducido grupo de los mejores CMS opensource
disponibles actualmente. Por tanto los gestores analizados tienen una valoración general
buena con respecto a las características de estudio. No hay ninguno que presente deficiencias
significativas en algún campo.
De hecho, hay ciertas características en las que es difícil hacer una mínima diferenciación de
calidad entre los contendientes. Por ejemplo, se esperaría que el CMS elegido tuviese unas
posibilidades de extensión e integración adecuadas, pero todos los gestores analizados tienen
funcionalidades sobresalientes en este aspecto.
Lo que se presenta en las siguientes secciones para cada una de las plataformas es una
reseña de aquello que lo particulariza sobre los demás. Se han intentando expresar las
diferencias existentes entre cada uno para hacerlos encajar en un determinado tipo de portal
objetivo.
Las valoraciones efectuadas se basan en buena parte en la experiencia de CTIC-CT en el
desarrollo de proyectos que han utilizados estos CMS; en algunos casos es una experiencia
mayor (Liferay, Drupal) y en el resto de los casos es más somera.
También se han tenido en cuenta experiencia y comparaciones elaboradas por entidades
independientes como CMS Report13, Idealware14 o Water&Stone15.
2.2.1 Liferay
Liferay es con diferencia el CMS más utilizado en el mundo Java. No solamente es un
gestor de contenidos web, sino que además cumple la especificación JSR-16816 de Java,
lo que lo convierte en un contenedor de portlets. En general Liferay es un CMS muy
completo y robusto en la mayoría de factores analizados. Muchas funcionalidades son
añadidas a través de portlets contribuidos.
13
CMS Report: http://cmsreport.com
14
Idealwear: http://www.idealware.org/reports/2010-os-cms
15
2010 Open Source CMS Report: http://www.waterandstone.com/book/2010-open-source-cms-market-share-report
16
JSR 168: Portlet Specification: http://www.jcp.org/en/jsr/detail?id=168
7
Las grandes ventajas de Liferay con respecto a las otras plataformas no Java son las que
en general tiene el propio lenguaje frente a otros lenguajes de script como PHP. Java
sobresale en tareas de integración entre aplicaciones, contando con una gran cantidad
de librerías profesionales, frameworks y especificaciones de gran madurez.
Además Liferay cuenta con una característica muy importante para algunos escenarios,
como es un soporte muy avanzado para gestionar varios portales en una misma instalación
o servidor (Multi Tenancy).
La desventaja de Liferay es que su potencia tiene un coste claro en la complejidad de
configuraciones y desarrollos llevados a cabo; en general los portlets de Java son más
complejos de implementar que los módulos de otros CMS.
También, se puede decir que el soporte de comunidad es inferior para este CMS que
para otros como puede ser Drupal; los foros no suelen ser de una especial ayuda y la
documentación disponible es francamente mejorable. La curva de aprendizaje inicial de
Liferay es sensiblemente más elevada.
2.2.2 Drupal
Drupal es el CMS que mejor relación presenta entre la facilidad y usabilidad de las tareas
más típicas de un portal web y la potencia y flexibilidad para construir sitios complejos.
Drupal es muy completo en lo que ser refiere a la construcción de estructuras complejas
para organizar la información; se pueden definir reglas detalladas para definir exactamente
qué contenido aparece en las diferentes secciones. También tiene un soporte muy
avanzado para definir nuevos tipos de contenido.
Además, Drupal es el CMS más avanzado en cuanto a funcionalidades de comunidad y web
2.0. Y más importante aún, Drupal es el único CMS que tiene un soporte nativo básico
para la publicación de información semántica en RDF.
Entre las desventajas que tiene Drupal está que su gran flexibilidad hace de él un CMS que
no es tan fácil de entender y configurar como pueden serlo Wordpress o Joomla.
Drupal tampoco dispone de las opciones avanzadas de workflow y gestión de usuarios que
sí tiene Plone.
2.2.3 Wordpress
Worpress es posiblemente el CMS más adecuado para webs de tamaño pequeño. Está
basado en la idea de blog, y todas sus funcionalidades giran alrededor de este tipo de webs,
pequeñas y de carácter personal.
Es la plataforma más fácil de instalar y utilizar, incluso por personas que no tienen un
perfil técnico. Dispone de muchos módulos adicionales contribuidos por la comunidad.
Otra de las ventajas de Wordpress es que es uno de los CMS que tiene una mayor
variedad de temas gráficos disponibles. Son muy fáciles de instalar y se pueden modificar
para adaptarlos a las necesidades específicas de un portal nuevo.
8
Pero toda esta facilidad de uso tiene una serie de desventajas. Wordpress, al contrario que
Drupal, está más orientado a un perfil de administrador gráfico, antes que a un perfil de
técnico programador. Por eso se hace más difícil la gestión de arquitecturas de la
información complejas, vistas elaboradas y nuevos tipos de contenidos.
Wordpress es además el CMS más débil en cuanto al soporte de roles y workflow de
publicación de contenidos.
2.2.4 Joomla
Joomla es el CMS que de alguna manera se sitúa por sus características entre Drupal y
Wordpress.
Es relativamente fácil su instalación y la preparación inicial de un portal, aunque no es tan
sencillo como Wordpress. Requiere cierto esfuerzo inicial para familiarizarse con las
estructuras de los sitios, los menús y la creación de contenidos.
Otra de las ventajas de Joomla es que una amplia variedad de funcionalidades está
disponible a través de módulos de terceros, como por ejemplo carros de compra o
funciones de comunidad.
Sin embargo Joomla no alcanza la potencia que tienen Drupal y Plone en funcionalidades
para la creación de estructuras de portal complejas. Por ejemplo es relativamente
complicada la generación de nuevos tipos de contenido y su visualización en varias
páginas diferenciadas del portal.
Tampoco cuenta con ningún tipo de soporte nativo para RDF.
2.2.5 Plone
Plone es, junto con Liferay, el más potente de los CMS estudiados. Ofrece un alto grado de
control para soportar estructuras y flujos de trabajo complejos. Y junto con esto, tiene un
conjunto de herramientas de administración y edición de gran usabilidad que facilitan el
control de los contenidos.
En general, Plone tiene el conjunto de funcionalidades más completo y maduro de los
CMS no Java. Sólo Drupal le aventaja en características de web 2.0.
En el lado negativo Plone cuenta con dos desventajas importantes. Primero que su
potencia tiene un coste claro en la complejidad; con una curva de aprendizaje elevada
para tareas como crear una estructura de sitio sofisticada o el manejo y creación de
módulos.
Además necesita de un entorno de instalación menos común que el de los CMS basados
en plataformas PHP/Apache o Java. Y al estar escrito en Python, un lenguaje menos común
que Java o PHP, es más difícil y cara la extensión de nuevas funcionalidades de portal.
9
2.3 Tabla comparativa de valoraciones
El cuadro de valoraciones calculado es el siguiente:
ASPECTO DEL CMS
PESO
Liferay 6
Drupal 7
Wordpress 3
Joomla 1.5
Plone 3.1
Facilidad de Instalación / Administración
*
Bien
Excelente
Excelente
Bien
Regular
Facilidad de uso
*
Bien
Bien
Excelente
Bien
Bien
Potencia gráfica y estructural
***
Excelente
Excelente
Excelente
Excelente
Excelente
Gestión de usuarios y workflow
***
Bien
Bien
Regular
Excelente
Excelente
Funcionalidad Web 2.0
**
Excelente
Excelente
Excelente
Bien
Bien
Posibilidades de extensión e integración
**
Excelente
Excelente
Excelente
Excelente
Excelente
Seguridad
**
Bien
Bien
Regular
Bien
Excelente
*
Bien
Excelente
Excelente
Excelente
Excelente
Regular
Bien
Regular
Regular
Regular
Java
PHP
PHP
PHP
Python
Soporte, tamaño de la comunidad
Soporte nativo semántico (RDF, RDFa, ...)
Plataforma
****
**
•
La columna peso refleja la importancia del aspecto estudiado dentro de los requisitos funcionales del portal a desarrollar.
•
Las valoraciones se dividen en tres niveles: Regular: el CMS ofrece un soporte correcto pero estrictamente básico para el aspecto analizado; Bien: el
CMS cuenta con funcionalidades para un aspecto estudiado que mejoran sensiblemente las ofrecidas por el resto de sistemas gestores; Excelente: el
CMS dispone, ya sea en la instalación básica o en módulos que estén disponibles, de las mejores características o funcionalidades posibles para un
aspecto concreto.
2.4 CKAN
17
CKAN (Comprehensive Knowledge Archive Network) es una plataforma web que facilita la
gestión de un registro de conjuntos de datos, su categorización y descubrimiento. CKAN
cuenta con un registro general en http://ckan.net que permite la inscripción de paquetes de
datos abiertos.
Pero CKAN además pone el software de su servidor a disposición pública como open source18.
Una entidad puede utilizar este software para montar su propio catálogo de datos. Existen a
día de hoy una serie de administraciones que han desarrollado sus registros utilizando una
instancia de CKAN propia.
Se presenta por tanto la posibilidad de desplegar y utilizar para el Catálogo Nacional un
servidor CKAN propio que realice toda la gestión del backoffice de los conjuntos de datos,
mientras que la parte pública del portal sea implementada por el CMS seleccionado. Esta
estrategia cuenta con ciertas ventajas, pero también con desventajas notables.
Ventajas:
•
CKAN cuenta con un modelo de datos ya establecido para la representación de
conjuntos de datos. Es un modelo maduro y completo desarrollado a partir de la
experiencia obtenida a lo largo de la vida de su registro de datos propio.
•
CKAN dispone de funcionalidades ya implementadas alrededor del registro y su
modelo de datos: etiquetado mediante tags, agrupaciones de conjuntos de datos
relacionados entre sí, una api rest para el uso del registro y la consulta de sus datos.
Desventajas:
•
Es tecnología Python. La instalación de un servidor CKAN obligaría al mantenimiento
de una plataforma de tecnología diferente a la del CMS elegido, si éste finalmente se
instala sobre PHP o Java.
•
Uno de lo aspectos valorados de los CMS es su soporte nativo de RDF. CKAN no
cuenta con este tipo de soporte nativo para el enriquecimiento semántico de los
conjuntos de datos publicados. Por ejemplo, el soporte nativo RDFa que Drupal tiene
en su versión 7 para asociar RDF a datos estructurados no sería aprovechado.
•
El uso de un servidor CKAN supondría el despliegue de una aplicación web diferente
al portal CMS. Esto obligaría a una configuración más complicada del espacio de URIs
y a un trabajo doble para integrar el look&feel (CSS, javascript, ...) en las dos
aplicaciones. Drupal cuenta con un módulo para integrar CKAN y su modelo de datos
con el portal, pero sólo está disponible para la versión 6.
17
CKAN – The Data Hub: http://ckan.net
18
CKAN – The Data Hub Software: http://ckan.org
11
En general puede decirse que el uso de un servidor CKAN dentro del Catálogo Nacional
tendría un coste para el desarrollo y mantenimiento del portal superior al peso de las
ventajas que aporta esta tecnología.
La mayor parte de las características con que cuenta CKAN, su modelo y las funcionalidades
como su API REST, son relativamente fáciles de implementar en los CMS comparados. Sin
embargo el desarrollo del portal en dos servidores, posiblemente de tecnologías diferentes,
supone un esfuerzo adicional considerable, tanto en la fase de construcción como en el
posterior mantenimiento y evolución.
Por tanto, es recomendable que la gestión del catálogo de conjuntos de datos se realice a
través de la gestión de contenidos disponible en el propio CMS del portal.
Una solución intermedia relacionada con el uso de CKAN sería la de publicar los conjuntos de
datos del Catálogo Nacional en el registro general de CKAN (en http://ckan.net/). Se podría
implementar un módulo en el CMS seleccionado que subiera (publicara) con una frecuencia
establecida los conjuntos de datos del catálogo al servidor CKAN.
2.5 Conclusiones finales
A partir de las valoraciones aproximadas resumidas en la tabla de la sección 2.3, se ha
realizado una ponderación numérica de cada uno de los factores analizados. Se ha relacionado
cada una de las escalas de valoración (regular, bueno, excelente) con una nota (1,2 y 3
respectivamente), y se ha multiplicado la nota por el factor peso (que numéricamente oscila
entre 1 y 4).
El resultado final obtenido para cada CMS se muestra en la siguiente tabla:
CMS
Valoración final
Drupal 7
47
Plone 3.1
44
Liferay 6
43
Joomla 1.5
42
Wordpress 3
39
Se propone por tanto Drupal 7 como el gestor de contenidos web para la construcción
del Portal OpenData Estatal.
PHP, el lenguaje de Drupal, es una plataforma de desarrollo perfectamente adecuada para el
tipo de proyecto que se quiere acometer; PHP se ha convertido en una lengua franca en el
12
mundo web, es muy productivo y utilizado en una gran cantidad de grandes proyectos open
source.
Sin embargo, al mismo tiempo Drupal es suficientemente flexible y potente para acometer el
desarrollo de módulos ad-hoc que permitan cumplir con las funcionalidades requeridas. Y su
amplia capacidad de extensión no compromete los posibles desarrollos que en el futuro tengan
que realizarse para la evolución del portal.
Por otro lado, Drupal es el CMS que cuenta con el soporte más avanzado relacionado con
características semánticas y RDF. Su versión 7 permite la asociación de campos de datos
estructurados a vocabularios RDF, y la inclusión de RDFa en las páginas web para describir
cada uno de los datos creados. Además cuenta con módulos adicionales, actualmente en
desarrollo, que permitirán la gestión visual por consola web del conjunto de vocabularios RDF
incluidos en el portal, su relación con los tipos de datos creados, y su renderización en
diferentes representaciones RDF: RDF/XML, Turtle o N3. Es, con mucha diferencia, el gestor
más avanzado en este aspecto.
13
3 Estudio de plataformas semánticas
Existen variedad de plataformas que permiten el almacenamiento y publicación de datos mediante
el uso de tecnologías semánticas (RDF, SPARQL...). En este apartado se van a comparar las
principales que se encuentran en el mercado junto con la opción de hacer un desarrollo propio,
utilizando una base de datos referencial para el almacenaje de los datos.
De entre las plataformas disponibles se han seleccionado las de más renombre en el mercado. El
estudio se basa en la experiencia obtenida por CTIC-CT a lo largo del desarrollo de proyectos
linked data y en el informe de resultados del Berlin SPARQL Benchmark de Febrero de 201119
Las plataformas analizadas son las siguientes:
•
4store
•
BigData21
•
BigOwlim22
•
Virtuoso23
•
Desarrollo Java: Desarrollo de aplicación Java basada en Jena que almacena los datos
en una base de datos relacional (MySQL, Oracle...)
20
Para realizar las pruebas se ha seleccionado la versión gratuita de cada una de las plataformas,
por lo que en caso de requerir un rendimiento mayor queda abierta la opción de utilizar las
versiones de pago, que suponen una clara mejora en el rendimiento al ofrecer la posibilidad de
realizar instalaciones clusterizadas y aumentar el número de peticiones que son capaces de
atender concurrentemente.
3.1 Necesidades funcionales semánticas del Portal OpenData Estatal
Desde el portal de datos del Portal OpenData Estatal será posible acceder a un conjunto de datos
en formatos semánticos. Este conjunto de datos comenzará siendo reducido, pero se prevé un
aumento de los mismos a medida que pase el tiempo, con el objetivo de transformar la estrategia
de apertura de datos en una estrategia linked data.
19
Berlin SPARQL Benchmark: http://www4.wiwiss.fu-berlin.de/bizer/BerlinSPARQLBenchmark/results/V6/index.html
20
4store: http://4store.org/
21
Bigdata: http://www.systap.com/bigdata.htm
22
BigOWLIM: http://www.ontotext.com/owlim/big/
23
Virtuoso: http://www.virtuoso.com/
14
Por otra parte, también estará disponible en formato semántico la metainformación referente al
catálogo de datos publicados, de forma que se pueda automatizar el proceso de búsqueda de en
los conjuntos de datos y el acceso a los propios datos. Para almacenar esta información se
utilizará el vocabulario DCAT24.
El volumen de información semántica será, en un principio, bastante bajo, puesto que el número
de tripletas RDF necesario para definir el catálogo de datos es pequeño y, en una primera fase,
serán pocos los conjuntos de datos que se exporten directamente en formato semántico. No
obstante, se deberá tener en cuenta a la hora de escoger la plataforma semántica a implantar,
que debe ser capaz de soportar una carga de datos elevada para poder garantizar su continuidad
en el tiempo.
La plataforma semántica seleccionada tiene que ser capaz de soportar tanto operaciones de
escritura (por ejemplo cada vez que se cree un conjunto de datos nuevo o que se añada un nuevo
conjunto exportado en formato semántico) y de lectura (por ejemplo cada vez que un usuario o
una aplicación quiera consultar los datos disponibles). Se debe tener en cuenta que, mientras
que las operaciones de escritura se realizarán de forma puntual, las de lectura se realizarán
de manera continuada, y será por tanto la respuesta a estas últimas la que más se valorará a la
hora de seleccionar la plataforma. Así pues, durante la fase de evaluación de resultados del
benchmarking realizado, tendremos en cuenta solamente la respuesta a las consultas
realizadas y no el tiempo empleado durante el proceso de carga.
3.2 Comparación de servidores semánticos
Dado que no ha sido posible lanzar el mismo conjunto de pruebas sobre los servidores
semánticos nativos que sobre la aplicación Java de desarrollo propio, se separarán los resultados
en apartados diferentes y se analizarán los resultados en conjunto en el apartado de
conclusiones.
3.2.1 Servidores semánticos nativos - Berlin SPARQL Benchmark (BSBM)
3.2.1.1 Máquina utilizada para la realización de las pruebas
•
•
Hardware:
◦
Procesador: Intel i7 950, 3.07GHz (4 cores)
◦
RAM: 24GB
◦
Discos duros: 2 x 1.8TB (7,200 rpm) SATA2.
Software:
◦
Sistema Operativo: Ubuntu 10.04 64-bit, Kernel 2.6.32-24-generic
▪
24
Sistema de ficheros: ext4
dcat Vocabulary resources & examples: http://vocab.deri.ie/dcat-overview
15
▪
◦
Particiones separadas para la aplicación y los datos
JVM: Version 1.6.0_20, OpenJDK 64-Bit Server VM (build 19.0-b09).
3.2.1.2 Descripción de las pruebas
Para cada uno de las plataformas semánticas se realizarán las pruebas con dos cargas de datos
diferentes, primero con 100 millones de tripletas y, a continuación, con 200 millones.
En cada caso se medirá:
•
Tiempo de carga de los datos. Como se comentaba anteriormente, para el caso de
uso del Portal OpenData Estatal este es un valor de poco peso, puesto que las cargas
de datos se realizarán de forma puntual y controlada.
•
Consultas procesadas: Análisis de los tiempos de respuesta de cada una de las
plataformas tras la ejecución de un amplio conjunto de consultas que incluye consultas
básicas y consultas complejas. Este dato es el que se priorizará a la hora de realizar la
selección, puesto que a medida que vayan apareciendo aplicaciones que consuman los
datos publicados, el número de consultas realizadas irá aumentando. El resultado se
dará en “Query Mixes per Hour (QmpH)”, siendo una “Query Mix” el conjunto de 12
consultas.
3.2.1.3 4store
Tiempos de carga:
100M tripletas
26min 42s
200M tripletas
1h 12min 04s
Consultas procesadas:
Número tripletas
QMpH
100M tripletas
5589
200M tripletas
4593
3.2.1.4 BigData
Tiempos de carga:
100M tripletas
200M tripletas
16
1h 3min 47s
3h 24min 25s
Consultas procesadas:
Número tripletas
QMpH
100M tripletas
2428
200M tripletas
1795
3.2.1.5 BigOwlin
Tiempos de carga:
100M tripletas
17min 22s
200M tripletas
38min 36s
Consultas procesadas:
Número tripletas
QMpH
100M tripletas
3534
200M tripletas
1795
3.2.1.6 Virtuoso
Tiempos de carga:
100M tripletas
1h 49min 26s
200M tripletas
3h 59min 38s
Consultas procesadas:
Número tripletas
QMpH
17
100M tripletas
7352
200M tripletas
4669
3.2.1.7 Gráfica resumen.
En la siguiente gráfica se muestra la comparativa de las plataformas atendiendo al número de
peticiones atendidas por unidad de tiempo:
8000
7000
6000
QMpH
5000
4store
BigData
BigOw lin
Virtuoso
4000
3000
2000
1000
0
100M
200M
Número de tripletas
3.2.2 Aplicación propia desarrollada en Java
3.2.2.1 Máquina utilizada para la realización de las pruebas
•
•
Hardware:
◦
Procesador: Intel(R) Core(TM)2 Quad CPU Q8300 @ 2.50GHz
◦
RAM: 8GB
◦
Disco duro: 1 x 350GB (7,200 rpm) SATA2.
Software:
◦
Sistema Operativo: Centos 5.5 64-bit, Kernel 2.6.18-194.32.1.el5
▪
◦
Sistema de ficheros: ext4
JVM: Version 1.6.0_20, OpenJDK 64-Bit Server VM (build 19.0-b09).
18
◦
Oracle: Oracle 11g + Módulo semántico
◦
MySQL: MySQL 5.0.77
◦
Apache Tomcat 6.0.32
3.2.2.2 Descripción de las pruebas
La aplicación Java desarrollada es capaz de funcionar con dos arquitecturas diferentes en función
de la tecnología utilizada para almacenar los datos. Una de ellas utiliza una base de datos Oracle
con un módulo específico que habilita las capacidades semánticas (Oracle Semantics) y la otra
utiliza una base de datos referencial estándar.
En ambos casos, se han almacenado 2 millones de tripletas del mismo tipo que las utilizadas en
el test “Berlin SPARQL Benchmark” descrito en el apartado anterior, y se han ejecutado las
mismas consultas que en dicho test para medir los tiempos de respuesta.
3.2.2.3 Java + Jena + Oracle Semantics
Consultas procesadas:
Número tripletas
2M tripletas
QMpH
20
3.2.2.4 Java + Jena SDB + MySQL
Consultas procesadas:
Número tripletas
2M tripletas
QMpH
160
3.3 Conclusiones finales
Como cabía esperar, puede observarse claramente que, pese a la diferencia del hardware, los
resultados obtenidos por los servidores nativos semánticos son sustancialmente
superiores a los obtenidos por las aplicaciones Java de desarrollo propio.
Para consolidar esta conclusión, se realizó una instalación básica de uno de los servidores
semánticos nativos, Virtuoso, en la misma máquina utilizada para llevar a cabo las pruebas con
las aplicaciones Java. La mejora encontrada en el rendimiento fue de órdenes de magnitud. Se
19
alcanzaron, para un volumen aproximado de 2 millones de tripletas, medias de hasta 2500
QmpH. Esta diferencia debería acentuarse a medida que creciera el número de datos
almacenados.
En el caso de decidirse por la implantación de una aplicación de desarrollo propio, se
simplificarían las tareas de instalación, mantenimiento y los conocimientos técnicos
requeridos a las personas asignadas, puesto que las tecnologías utilizadas son de uso común.
La instalación de una de estas aplicaciones tendrá sentido en aquellos casos en que se prevea
que el volumen de datos almacenados no va a ser muy elevado.
En el caso del Portal OpenData Estatal, es previsible que, con el paso del tiempo, el volumen de
información semántica almacenada sea elevado, por lo que se recomienda la instalación de
alguno de los servidores semánticos nativos. Observando la gráfica resumen puede verse que
dos de ellos destacan especialmente sobre los demás: 4store y virtuoso. Si se tiene en cuenta el
volumen de datos estimados para el Portal OpenData Estatal durante los primeros años de vida,
los resultados obtenidos por virtuoso son superiores a los mostrados por 4store.
Teniendo en cuenta los comentarios anteriores, se propone utilizar virtuoso como servidor
semántico. Es importante señalar que, aunque la versión Open Source gratuita de virtuoso
cumple más que sobradamente con los requerimientos del Portal OpenData Estatal, existe
también una versión de código cerrado con diferentes licencias que aumentan sustancialmente su
rendimiento (más información en: http://virtuoso.openlinksw.com/pricing/).
20
4 Arquitectura propuesta
Se muestra a continuación el gráfico resumen que representa la arquitectura propuesta para el portal OpenData Estatal en vista a los resultados del
estudio: Drupal como gestor de contenidos web y Virtuoso como servidor nativo de tecnología semántica.