CMS Definicion

Estudio de plataformas tecnolgicasdatos.gob.es

En colaboracin con

Las opiniones recogidas en este documento no secorresponden, necesariamente, con las de ningunode los organismos pblicos participantes en estainiciativa.

Contenidos

I. Propuesta de trabajo. ...................................................................................................... 21 Objetivo. ........................................................................................................................ 22 Estudio de CMS............................................................................................................. 3

2.1 Aspectos valorados de los CMS................................................................................. 42.1.1 Facilidad de instalacin / administracin............................................................... 42.1.2 Facilidad de uso ................................................................................................... 42.1.3 Potencia grfica y estructural ............................................................................... 42.1.4 Gestin de usuarios y workflows .......................................................................... 52.1.5 Funcionalidades Web 2.0 ..................................................................................... 52.1.6 Posibilidades de extensin e integracin .............................................................. 52.1.7 Seguridad ............................................................................................................. 52.1.8 Soporte, tamao de la comunidad ........................................................................ 62.1.9 Soporte nativo semntico (RDF, RDFa, ).......................................................... 62.1.10 Plataforma .......................................................................................................... 6

2.2 Valoraciones de los CMS ........................................................................................... 72.2.1 Liferay .................................................................................................................. 72.2.2 Drupal................................................................................................................... 82.2.3 Wordpress............................................................................................................ 82.2.4 Joomla.................................................................................................................. 92.2.5 Plone .................................................................................................................... 9

2.3 Tabla comparativa de valoraciones .......................................................................... 102.4 CKAN....................................................................................................................... 112.5 Conclusiones finales ................................................................................................ 12

3 Estudio de plataformas semnticas .......................................................................... 14

3.1 Necesidades funcionales semnticas del Portal OpenData Estatal.......................... 143.2 Comparacin de servidores semnticos................................................................... 15

3.2.1Servidores semnticos nativos - Berlin SPARQL Benchmark (BSBM) ................ 15

3.2.1.1 Mquina utilizada para la realizacin de las pruebas................................. 15

3.2.1.2 Descripcin de las pruebas........................................................................ 16

3.2.1.3 4store ........................................................................................................ 16

13.2.1.4 BigData...................................................................................................... 16

3.2.1.5 BigOwlin .................................................................................................... 17

3.2.1.6 Virtuoso ..................................................................................................... 17

3.2.1.7 Grfica resumen. ....................................................................................... 18

3.2.2 Aplicacin propia desarrollada en Java.............................................................. 18

3.2.2.1 Mquina utilizada para la realizacin de las pruebas................................. 18

3.2.2.2 Descripcin 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 ................................................................................................ 194 Arquitectura propuesta............................................................................................... 20

2I. Propuesta de trabajo.

1 Objetivo.

El objetivo de este documento es presentar un anlisis comparativo de las diferentes tecnologasdisponibles como plataformas para el desarrollo del portal OpenData Estatal.

La plataforma a desarrollar tendr dos partes bien definidas. Primeramente constar de unsistema de gestin de contenidos web (CMS) que soportar la creacin y gestin de laspginas web del portal por un lado, y tambin el mantenimiento del propio catlogo, formado porlos conjuntos de datos publicados por el Portal OpenData Estatal. La primera parte del informevalorar los mejores CMS disponibles actualmente y propondr la seleccin de uno de ellos paraeste proyecto.

Adems, la plataforma implementada deber contar con tecnologa semntica que permita lapublicacin de los metadatos del Catlogo en RDF1, as como la publicacin de datos en RDF deaquellos conjuntos de naturaleza semntica. Esta plataforma semntica deber exponer los datossiguiendo los principios de Linked Data2 y deber implementar un punto SPARQL3. La segundaparte del informe analiza las opciones tecnolgicas disponibles que mejor se adecuan a lasnecesidades del nuevo portal.

1 Resource Description Framework (RDF): http://www.w3.org/RDF/2 Linked Data - Connect Distributed Data across the Web: http://linkeddata.org3 SPARQL Query Language for RDF: http://www.w3.org/TR/rdf-sparql-query

32 Estudio de CMS

Existe una enorme variedad de gestores de contenidos web (CMS Content ManagementSystem) en el mercado. Para el objeto de este estudio se ha realizado un filtro previo y slo sehan comparado los mejores gestores de contenido web a fecha de la realizacin del anlisis.

De forma genrica, para la seleccin inicial de los candidatos se han tenido en cuenta dosgrandes criterios de seleccin:

OpenSource. El software libre no impone un coste de licencia, y cuenta con las grandesventajas del cdigo abierto: flexibilidad, seguridad y rapidez en las tareas de desarrollo yactualizacin.

Cuota de uso y relevancia. El uso de tecnologas con la mayor comunidad de usuariosposible ofrece importantes ventajas: mayor soporte disponible, mayor nmero de mdulosde terceros desarrollados y probados por la comunidad, garanta de evolucin de laplataforma.

Atendiendo a los criterios generales mencionados se han seleccionado un grupo de cinco CMScandidatos:

Liferay4

Drupal5

Wordpress6

Joomla7

Plone8

En el resto del informe se describen las funcionalidades y caractersticas que se han comparadoatendiendo a las necesidades del nuevo portal. Tambin se presenta un resumen de las virtudes ylas desventajas de cada uno de los CMS y una puntuacin final en forma de tabla.

4 Liferay: http://www.liferay.com5 Drupal: http://drupal.org6 WordPress: http://wordpress.org7 Joomla Spanish: http://www.joomlaspanish.org8 Plone CMS: http://plone.org

42.1 Aspectos valorados de los CMS

Para la comparacin de los diferentes gestores de contenido se han agrupado en una serie deaspectos diferenciados el conjunto de las funcionalidades y caractersticas que tienen este tipode sistemas. A continuacin se describen cada uno de estos aspectos y los puntos mssignificativos que se han comparado.

2.1.1 Facilidad de instalacin / administracin

Facilidad con que se pueden encontrar un proveedor de servicios con soporte en susservidores para la plataforma tecnolgica seleccionada. Costes de hosting.

Facilidad para la instalacin y despliegue de un portal bsico vaco.

Usabilidad de las vistas de administracin.

Cantidad y calidad de la documentacin de administracin disponible.

Soporte visual para la gestin de mdulos de terceros incluidos.

Soporte visual para la gestin de temas y estilos grficos soportados.

Soporte para la actualizacin de la plataforma a una nueva versin.

2.1.2 Facilidad de uso

Inclusin de editores de texto enriquecido.

Facilidad de inclusin de imgenes y elementos multimedia embebidos en laspginas.

Control de versiones sobre los contenidos creados.

Facilidad en la gestin de barras de men, cabeceras y pies.

Soporte para la gestin de imgenes y documentos subidos al portal. Herramientapara buscar y eliminar recursos que han sido subidos pero ya no son utilizados.

Usabilidad general de los controles y vistas.

2.1.3 Potencia grfica y estructural

Inclusin de un sistema de gestin de temas grficos. Facilidad en la administracinde los temas grficos soportados.

Disponibilidad de repositorios externos con temas grficos libres. Cantidad y calidadde temas grficos disponibles.

Flexibilidad para la creacin de nuevos temas grficos o para la modificacin de losexistentes.

5 Posibilidad de incluir el mximo de caractersticas HTML y CSS disponibles en lacreacin de un tema grfico.

Facilidad y flexibilidad en la creacin de estructuras jerrquicas complejas para loscontenidos de un portal.

Creacin de nuevos tipos de contenido.

Disponibilidad de funcionalidades tpicas ya implementadas: buscador de contenidos,tipos de contenido ms utilizados (noticias, eventos, etc.)

2.1.4 Gestin de usuarios y workflows

Gestin de usuarios, roles y permisos sobre tipos de contenido y secciones del portal.

Posibilidad de dividir las tareas de creacin, modificacin, revisin y publicacin delos contenidos.

Posibilidad y facilidad de creacin de workflows entre diferentes roles con las fases depublicacin de contenidos.

2.1.5 Funcionalidades Web 2.0

Soporte para comentarios sobre los contenidos del portal. Posibilidad de configuracinpara diferentes niveles de autenticacin, permisos y moderacin.

Soporte para la votacin de contenidos del portal. Posibilidad de configuracin paradiferentes niveles de autenticacin y permisos.

Funcionalidad para la configuracin y publicacin de feeds de los contenidos del portal.

Soporte integrado para la creacin de blogs.

2.1.6 Posibilidades de extensin e integracin

Sistema par la creacin de mdulos que extiendan la funcionalidad bsica del CMS.

Disponibilidad de herramientas de desarrollo especficas del CMS que facilitan lacreacin de nuevos mdulos y la extensin de las funcionalidades.

Facilidad de integracin con otros sistemas: posibilidad de uso de diferentes sistemasde persistencia; cohesin con diferentes sistemas de autenticacin y autorizacin;existencia de APIs para la conexin con otros sistemas mediante servicios web.

2.1.7 Seguridad

Volumen de problemas de seguridad y vulnerabilidades encontrados para el CMS yregistrados por entidades independientes.

6 La comunidad del CMS dispone de una metodologa y plan precisos para eldescubrimiento y reparacin de vulnerabilidades y problemas de seguridad.

2.1.8 Soporte, tamao de la comunidad

Los fuentes del CMS han sido soportados por la comunidad como un paqueteopensource por un periodo de tiempo largo.

Cantidad de entidades y consultoras que dan soporte o basan sus servicios yproductos en el CMS.

Existencia de libros publicados de calidad sobre el uso del CMS.

La comunidad del CMS cuenta con foros dedicados para la resolucin de problemasespecficos de los usuarios.

2.1.9 Soporte nativo semntico (RDF, RDFa, )

Existencia de soporte nativo para la gestin de vocabularios y ontologas RDF.Calidad del backoffice para realizar dicha gestin de vocabularios.

Existencia de funcionalidades nativas en el CMS para la asociacin entre los contenidosestructurados del portal y los vocabularios RDF gestionados. Posibilidad de asociarcada tipo estructurado a una o varias clases RDF y mapear parte de los campos del tipoestructurado a propiedades RDF.

Posibilidad de publicar las asociaciones RDF creadas en formatos semnticos:

Enriquecimiento de las pginas HTML de las instancias de contenidosestructurados con RDFa9.

Posibilidad de publicacin de la informacin semntica de los contenidos creadosmediante formatos especficos RDF: RDF/XML10, Turtle11, N312.

2.1.10 Plataforma

A priori el entorno de ejecucin o lenguaje de programacin de cada CMS no suponeuna ventaja decisiva para ninguno de ellos. Sin embargo s que se debe tener en cuentala orientacin general que tienen cada una de las plataformas:

Java/JEE. Orientado a entornos enterprise. Java sobresale en utilidades ylibreras de soporte para funciones de interoperabilidad. Es un lenguajesemicompilado lo que lo hace ms rpido que lenguajes de script interpretados.

9 RDFa Primer - Bridging the Human and Data Webs: http://www.w3.org/TR/xhtml-rdfa-primer10 RDF/XML Syntax Specification: http://www.w3.org/TR/rdf-syntax-grammar11 Turtle - Terse RDF Triple Language: http://www.w3.org/TeamSubmission/turtle12 Notation 3: http://www.w3.org/DesignIssues/Notation3.html

7 PHP. Muy orientado al desarrollo web. Tiene una cuerva de aprendizaje muy baja yse alcanza una gran productividad con poco esfuerzo. Es un lenguaje de scriptinterpretado lo que lo hace algo ms lento en ejecucin que java.

Python. Orientado al desarrollo web. Es un lenguaje ms moderno y mejordiseado que PHP, pero algo ms complejo y difcil. Es un lenguaje de scriptinterpretado lo que lo hace algo ms lento en ejecucin que java.

2.2 Valoraciones de los CMS

A continuacin se presenta una valoracin resumida de las ventajas y desventajas de cada unode los CMS.

Hay que resear que dentro del amplio espectro existente de gestores de contenidos web, loscinco preseleccionados forman parte del reducido grupo de los mejores CMS opensourcedisponibles actualmente. Por tanto los gestores analizados tienen una valoracin generalbuena con respecto a las caractersticas de estudio. No hay ninguno que presente deficienciassignificativas en algn campo.

De hecho, hay ciertas caractersticas en las que es difcil hacer una mnima diferenciacin decalidad entre los contendientes. Por ejemplo, se esperara que el CMS elegido tuviese unasposibilidades de extensin e integracin adecuadas, pero todos los gestores analizados tienenfuncionalidades sobresalientes en este aspecto.

Lo que se presenta en las siguientes secciones para cada una de las plataformas es unaresea de aquello que lo particulariza sobre los dems. Se han intentando expresar lasdiferencias existentes entre cada uno para hacerlos encajar en un determinado tipo de portalobjetivo.

Las valoraciones efectuadas se basan en buena parte en la experiencia de CTIC-CT en eldesarrollo de proyectos que han utilizados estos CMS; en algunos casos es una experienciamayor (Liferay, Drupal) y en el resto de los casos es ms somera.

Tambin se han tenido en cuenta experiencia y comparaciones elaboradas por entidadesindependientes como CMS Report13, Idealware14 o Water&Stone15.

2.2.1 Liferay

Liferay es con diferencia el CMS ms utilizado en el mundo Java. No solamente es ungestor de contenidos web, sino que adems cumple la especificacin JSR-16816 de Java,lo que lo convierte en un contenedor de portlets. En general Liferay es un CMS muycompleto y robusto en la mayora de factores analizados. Muchas funcionalidades sonaadidas a travs de portlets contribuidos.

13 CMS Report: http://cmsreport.com14 Idealwear: http://www.idealware.org/reports/2010-os-cms15 2010 Open Source CMS Report: http://www.waterandstone.com/book/2010-open-source-cms-market-share-report16 JSR 168: Portlet Specification: http://www.jcp.org/en/jsr/detail?id=168

8Las grandes ventajas de Liferay con respecto a las otras plataformas no Java son las queen general tiene el propio lenguaje frente a otros lenguajes de script como PHP. Javasobresale en tareas de integracin entre aplicaciones, contando con una gran cantidadde libreras profesionales, frameworks y especificaciones de gran madurez.

Adems Liferay cuenta con una caracterstica muy importante para algunos escenarios,como es un soporte muy avanzado para gestionar varios portales en una misma instalacino servidor (Multi Tenancy).

La desventaja de Liferay es que su potencia tiene un coste claro en la complejidad deconfiguraciones y desarrollos llevados a cabo; en general los portlets de Java son mscomplejos de implementar que los mdulos de otros CMS.

Tambin, se puede decir que el soporte de comunidad es inferior para este CMS quepara otros como puede ser Drupal; los foros no suelen ser de una especial ayuda y ladocumentacin disponible es francamente mejorable. La curva de aprendizaje inicial deLiferay es sensiblemente ms elevada.

2.2.2 Drupal

Drupal es el CMS que mejor relacin presenta entre la facilidad y usabilidad de las tareasms tpicas de un portal web y la potencia y flexibilidad para construir sitios complejos.

Drupal es muy completo en lo que ser refiere a la construccin de estructuras complejaspara organizar la informacin; se pueden definir reglas detalladas para definir exactamentequ contenido aparece en las diferentes secciones. Tambin tiene un soporte muyavanzado para definir nuevos tipos de contenido.

Adems, Drupal es el CMS ms avanzado en cuanto a funcionalidades de comunidad y web2.0. Y ms importante an, Drupal es el nico CMS que tiene un soporte nativo bsicopara la publicacin de informacin semntica en RDF.

Entre las desventajas que tiene Drupal est que su gran flexibilidad hace de l un CMS queno es tan fcil de entender y configurar como pueden serlo Wordpress o Joomla.

Drupal tampoco dispone de las opciones avanzadas de workflow y gestin de usuarios ques tiene Plone.

2.2.3 Wordpress

Worpress es posiblemente el CMS ms adecuado para webs de tamao pequeo. Estbasado en la idea de blog, y todas sus funcionalidades giran alrededor de este tipo de webs,pequeas y de carcter personal.

Es la plataforma ms fcil de instalar y utilizar, incluso por personas que no tienen unperfil tcnico. Dispone de muchos mdulos adicionales contribuidos por la comunidad.

Otra de las ventajas de Wordpress es que es uno de los CMS que tiene una mayorvariedad de temas grficos disponibles. Son muy fciles de instalar y se pueden modificarpara adaptarlos a las necesidades especficas de un portal nuevo.

9Pero toda esta facilidad de uso tiene una serie de desventajas. Wordpress, al contrario queDrupal, est ms orientado a un perfil de administrador grfico, antes que a un perfil detcnico programador. Por eso se hace ms difcil la gestin de arquitecturas de lainformacin complejas, vistas elaboradas y nuevos tipos de contenidos.

Wordpress es adems el CMS ms dbil en cuanto al soporte de roles y workflow depublicacin de contenidos.

2.2.4 Joomla

Joomla es el CMS que de alguna manera se sita por sus caractersticas entre Drupal yWordpress.

Es relativamente fcil su instalacin y la preparacin inicial de un portal, aunque no es tansencillo como Wordpress. Requiere cierto esfuerzo inicial para familiarizarse con lasestructuras de los sitios, los mens y la creacin de contenidos.

Otra de las ventajas de Joomla es que una amplia variedad de funcionalidades estdisponible a travs de mdulos de terceros, como por ejemplo carros de compra ofunciones de comunidad.

Sin embargo Joomla no alcanza la potencia que tienen Drupal y Plone en funcionalidadespara la creacin de estructuras de portal complejas. Por ejemplo es relativamentecomplicada la generacin de nuevos tipos de contenido y su visualizacin en variaspginas diferenciadas del portal.

Tampoco cuenta con ningn tipo de soporte nativo para RDF.

2.2.5 Plone

Plone es, junto con Liferay, el ms potente de los CMS estudiados. Ofrece un alto grado decontrol para soportar estructuras y flujos de trabajo complejos. Y junto con esto, tiene unconjunto de herramientas de administracin y edicin de gran usabilidad que facilitan elcontrol de los contenidos.

En general, Plone tiene el conjunto de funcionalidades ms completo y maduro de losCMS no Java. Slo Drupal le aventaja en caractersticas de web 2.0.

En el lado negativo Plone cuenta con dos desventajas importantes. Primero que supotencia tiene un coste claro en la complejidad; con una curva de aprendizaje elevadapara tareas como crear una estructura de sitio sofisticada o el manejo y creacin demdulos.

Adems necesita de un entorno de instalacin menos comn que el de los CMS basadosen plataformas PHP/Apache o Java. Y al estar escrito en Python, un lenguaje menos comnque Java o PHP, es ms difcil y cara la extensin de nuevas funcionalidades de portal.

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 Instalacin / Administracin * Bien Excelente Excelente Bien Regular

Facilidad de uso * Bien Bien Excelente Bien Bien

Potencia grfica y estructural * * * Excelente Excelente Excelente Excelente Excelente

Gestin de usuarios y workflow * * * Bien Bien Regular Excelente Excelente

Funcionalidad Web 2.0 * * Excelente Excelente Excelente Bien Bien

Posibilidades de extensin e integracin * * Excelente Excelente Excelente Excelente Excelente

Seguridad * * Bien Bien Regular Bien Excelente

Soporte, tamao de la comunidad * Bien Excelente Excelente Excelente Excelente

Soporte nativo semntico (RDF, RDFa, ...) * * * * Regular Bien Regular Regular Regular

Plataforma * * Java PHP PHP PHP Python

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 bsico 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 instalacin bsica o en mdulos que estn disponibles, de las mejores caractersticas o funcionalidades posibles para unaspecto concreto.

11

2.4 CKAN

CKAN17 (Comprehensive Knowledge Archive Network) es una plataforma web que facilita lagestin de un registro de conjuntos de datos, su categorizacin y descubrimiento. CKANcuenta con un registro general en http://ckan.net que permite la inscripcin de paquetes dedatos abiertos.

Pero CKAN adems pone el software de su servidor a disposicin pblica como open source18.Una entidad puede utilizar este software para montar su propio catlogo de datos. Existen ada de hoy una serie de administraciones que han desarrollado sus registros utilizando unainstancia de CKAN propia.

Se presenta por tanto la posibilidad de desplegar y utilizar para el Catlogo Nacional unservidor CKAN propio que realice toda la gestin del backoffice de los conjuntos de datos,mientras que la parte pblica del portal sea implementada por el CMS seleccionado. Estaestrategia cuenta con ciertas ventajas, pero tambin con desventajas notables.

Ventajas:

CKAN cuenta con un modelo de datos ya establecido para la representacin deconjuntos de datos. Es un modelo maduro y completo desarrollado a partir de laexperiencia obtenida a lo largo de la vida de su registro de datos propio.

CKAN dispone de funcionalidades ya implementadas alrededor del registro y sumodelo de datos: etiquetado mediante tags, agrupaciones de conjuntos de datosrelacionados entre s, una api rest para el uso del registro y la consulta de sus datos.

Desventajas:

Es tecnologa Python. La instalacin de un servidor CKAN obligara al mantenimientode una plataforma de tecnologa diferente a la del CMS elegido, si ste finalmente seinstala sobre PHP o Java.

Uno de lo aspectos valorados de los CMS es su soporte nativo de RDF. CKAN nocuenta con este tipo de soporte nativo para el enriquecimiento semntico de losconjuntos de datos publicados. Por ejemplo, el soporte nativo RDFa que Drupal tieneen su versin 7 para asociar RDF a datos estructurados no sera aprovechado.

El uso de un servidor CKAN supondra el despliegue de una aplicacin web diferenteal portal CMS. Esto obligara a una configuracin ms complicada del espacio de URIsy a un trabajo doble para integrar el look&feel (CSS, javascript, ...) en las dosaplicaciones. Drupal cuenta con un mdulo para integrar CKAN y su modelo de datoscon el portal, pero slo est disponible para la versin 6.

17 CKAN The Data Hub: http://ckan.net18 CKAN The Data Hub Software: http://ckan.org

12

En general puede decirse que el uso de un servidor CKAN dentro del Catlogo Nacionaltendra un coste para el desarrollo y mantenimiento del portal superior al peso de lasventajas que aporta esta tecnologa.

La mayor parte de las caractersticas con que cuenta CKAN, su modelo y las funcionalidadescomo su API REST, son relativamente fciles de implementar en los CMS comparados. Sinembargo el desarrollo del portal en dos servidores, posiblemente de tecnologas diferentes,supone un esfuerzo adicional considerable, tanto en la fase de construccin como en elposterior mantenimiento y evolucin.

Por tanto, es recomendable que la gestin del catlogo de conjuntos de datos se realice atravs de la gestin de contenidos disponible en el propio CMS del portal.

Una solucin intermedia relacionada con el uso de CKAN sera la de publicar los conjuntos dedatos del Catlogo Nacional en el registro general de CKAN (en http://ckan.net/). Se podraimplementar un mdulo en el CMS seleccionado que subiera (publicara) con una frecuenciaestablecida los conjuntos de datos del catlogo al servidor CKAN.

2.5 Conclusiones finales

A partir de las valoraciones aproximadas resumidas en la tabla de la seccin 2.3, se harealizado una ponderacin numrica de cada uno de los factores analizados. Se ha relacionadocada una de las escalas de valoracin (regular, bueno, excelente) con una nota (1,2 y 3respectivamente), y se ha multiplicado la nota por el factor peso (que numricamente oscilaentre 1 y 4).

El resultado final obtenido para cada CMS se muestra en la siguiente tabla:

CMS Valoracin 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 construccindel Portal OpenData Estatal.

PHP, el lenguaje de Drupal, es una plataforma de desarrollo perfectamente adecuada para eltipo de proyecto que se quiere acometer; PHP se ha convertido en una lengua franca en el

13

mundo web, es muy productivo y utilizado en una gran cantidad de grandes proyectos opensource.

Sin embargo, al mismo tiempo Drupal es suficientemente flexible y potente para acometer eldesarrollo de mdulos ad-hoc que permitan cumplir con las funcionalidades requeridas. Y suamplia capacidad de extensin no compromete los posibles desarrollos que en el futuro tenganque realizarse para la evolucin del portal.

Por otro lado, Drupal es el CMS que cuenta con el soporte ms avanzado relacionado concaractersticas semnticas y RDF. Su versin 7 permite la asociacin de campos de datosestructurados a vocabularios RDF, y la inclusin de RDFa en las pginas web para describircada uno de los datos creados. Adems cuenta con mdulos adicionales, actualmente endesarrollo, que permitirn la gestin visual por consola web del conjunto de vocabularios RDFincluidos en el portal, su relacin con los tipos de datos creados, y su renderizacin endiferentes representaciones RDF: RDF/XML, Turtle o N3. Es, con mucha diferencia, el gestorms avanzado en este aspecto.

14

3 Estudio de plataformas semnticas

Existen variedad de plataformas que permiten el almacenamiento y publicacin de datos medianteel uso de tecnologas semnticas (RDF, SPARQL...). En este apartado se van a comparar lasprincipales que se encuentran en el mercado junto con la opcin 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 ms renombre en el mercado. Elestudio se basa en la experiencia obtenida por CTIC-CT a lo largo del desarrollo de proyectoslinked data y en el informe de resultados del Berlin SPARQL Benchmark de Febrero de 201119

Las plataformas analizadas son las siguientes:

4store20

BigData21

BigOwlim22

Virtuoso23

Desarrollo Java: Desarrollo de aplicacin Java basada en Jena que almacena los datosen una base de datos relacional (MySQL, Oracle...)

Para realizar las pruebas se ha seleccionado la versin gratuita de cada una de las plataformas,por lo que en caso de requerir un rendimiento mayor queda abierta la opcin de utilizar lasversiones de pago, que suponen una clara mejora en el rendimiento al ofrecer la posibilidad derealizar instalaciones clusterizadas y aumentar el nmero de peticiones que son capaces deatender concurrentemente.

3.1 Necesidades funcionales semnticas del Portal OpenData Estatal

Desde el portal de datos del Portal OpenData Estatal ser posible acceder a un conjunto de datosen formatos semnticos. Este conjunto de datos comenzar siendo reducido, pero se prev unaumento de los mismos a medida que pase el tiempo, con el objetivo de transformar la estrategiade apertura de datos en una estrategia linked data.

19 Berlin SPARQL Benchmark: http://www4.wiwiss.fu-berlin.de/bizer/BerlinSPARQLBenchmark/results/V6/index.html20 4store: http://4store.org/21 Bigdata: http://www.systap.com/bigdata.htm22 BigOWLIM: http://www.ontotext.com/owlim/big/23 Virtuoso: http://www.virtuoso.com/

15

Por otra parte, tambin estar disponible en formato semntico la metainformacin referente alcatlogo de datos publicados, de forma que se pueda automatizar el proceso de bsqueda de enlos conjuntos de datos y el acceso a los propios datos. Para almacenar esta informacin seutilizar el vocabulario DCAT24.

El volumen de informacin semntica ser, en un principio, bastante bajo, puesto que el nmerode tripletas RDF necesario para definir el catlogo de datos es pequeo y, en una primera fase,sern pocos los conjuntos de datos que se exporten directamente en formato semntico. Noobstante, se deber tener en cuenta a la hora de escoger la plataforma semntica a implantar,que debe ser capaz de soportar una carga de datos elevada para poder garantizar su continuidaden el tiempo.

La plataforma semntica seleccionada tiene que ser capaz de soportar tanto operaciones deescritura (por ejemplo cada vez que se cree un conjunto de datos nuevo o que se aada un nuevoconjunto exportado en formato semntico) y de lectura (por ejemplo cada vez que un usuario ouna aplicacin quiera consultar los datos disponibles). Se debe tener en cuenta que, mientrasque las operaciones de escritura se realizarn de forma puntual, las de lectura se realizarnde manera continuada, y ser por tanto la respuesta a estas ltimas la que ms se valorar a lahora de seleccionar la plataforma. As pues, durante la fase de evaluacin de resultados delbenchmarking realizado, tendremos en cuenta solamente la respuesta a las consultasrealizadas y no el tiempo empleado durante el proceso de carga.

3.2 Comparacin de servidores semnticos

Dado que no ha sido posible lanzar el mismo conjunto de pruebas sobre los servidoressemnticos nativos que sobre la aplicacin Java de desarrollo propio, se separarn los resultadosen apartados diferentes y se analizarn los resultados en conjunto en el apartado deconclusiones.

3.2.1 Servidores semnticos nativos - Berlin SPARQL Benchmark (BSBM)

3.2.1.1 Mquina utilizada para la realizacin 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

Sistema de ficheros: ext4

24 dcat Vocabulary resources & examples: http://vocab.deri.ie/dcat-overview

16

Particiones separadas para la aplicacin y los datos

JVM: Version 1.6.0_20, OpenJDK 64-Bit Server VM (build 19.0-b09).

3.2.1.2 Descripcin de las pruebas

Para cada uno de las plataformas semnticas se realizarn las pruebas con dos cargas de datosdiferentes, primero con 100 millones de tripletas y, a continuacin, con 200 millones.

En cada caso se medir:

Tiempo de carga de los datos. Como se comentaba anteriormente, para el caso deuso del Portal OpenData Estatal este es un valor de poco peso, puesto que las cargasde datos se realizarn de forma puntual y controlada.

Consultas procesadas: Anlisis de los tiempos de respuesta de cada una de lasplataformas tras la ejecucin de un amplio conjunto de consultas que incluye consultasbsicas y consultas complejas. Este dato es el que se priorizar a la hora de realizar laseleccin, puesto que a medida que vayan apareciendo aplicaciones que consuman losdatos publicados, el nmero de consultas realizadas ir aumentando. El resultado sedar en Query Mixes per Hour (QmpH), siendo una Query Mix el conjunto de 12consultas.

3.2.1.3 4store

Tiempos de carga:

100M tripletas 200M tripletas

26min 42s 1h 12min 04s

Consultas procesadas:

Nmero tripletas QMpH

100M tripletas 5589

200M tripletas 4593

3.2.1.4 BigData

Tiempos de carga:


17

1h 3min 47s 3h 24min 25s



100M tripletas 2428

200M tripletas 1795

3.2.1.5 BigOwlin

Tiempos de carga:


17min 22s 38min 36s



100M tripletas 3534

200M tripletas 1795

3.2.1.6 Virtuoso

Tiempos de carga:


1h 49min 26s 3h 59min 38s



18

100M tripletas 7352

200M tripletas 4669

3.2.1.7 Grfica resumen.

En la siguiente grfica se muestra la comparativa de las plataformas atendiendo al nmero depeticiones atendidas por unidad de tiempo:

100M 200M0

1000

2000

3000

4000

5000

6000

7000

8000

4storeBigDataBigOw linVirtuoso

Nmero de tripletas

QM

pH

3.2.2 Aplicacin propia desarrollada en Java

3.2.2.1 Mquina utilizada para la realizacin 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).

19

Oracle: Oracle 11g + Mdulo semntico

MySQL: MySQL 5.0.77

Apache Tomcat 6.0.32

3.2.2.2 Descripcin de las pruebas

La aplicacin Java desarrollada es capaz de funcionar con dos arquitecturas diferentes en funcinde la tecnologa utilizada para almacenar los datos. Una de ellas utiliza una base de datos Oraclecon un mdulo especfico que habilita las capacidades semnticas (Oracle Semantics) y la otrautiliza una base de datos referencial estndar.

En ambos casos, se han almacenado 2 millones de tripletas del mismo tipo que las utilizadas enel test Berlin SPARQL Benchmark descrito en el apartado anterior, y se han ejecutado lasmismas consultas que en dicho test para medir los tiempos de respuesta.

3.2.2.3 Java + Jena + Oracle Semantics



2M tripletas 20

3.2.2.4 Java + Jena SDB + MySQL



2M tripletas 160

3.3 Conclusiones finales

Como caba esperar, puede observarse claramente que, pese a la diferencia del hardware, losresultados obtenidos por los servidores nativos semnticos son sustancialmentesuperiores a los obtenidos por las aplicaciones Java de desarrollo propio.

Para consolidar esta conclusin, se realiz una instalacin bsica de uno de los servidoressemnticos nativos, Virtuoso, en la misma mquina utilizada para llevar a cabo las pruebas conlas aplicaciones Java. La mejora encontrada en el rendimiento fue de rdenes de magnitud. Se

20

alcanzaron, para un volumen aproximado de 2 millones de tripletas, medias de hasta 2500QmpH. Esta diferencia debera acentuarse a medida que creciera el nmero de datosalmacenados.

En el caso de decidirse por la implantacin de una aplicacin de desarrollo propio, sesimplificaran las tareas de instalacin, mantenimiento y los conocimientos tcnicosrequeridos a las personas asignadas, puesto que las tecnologas utilizadas son de uso comn.La instalacin de una de estas aplicaciones tendr sentido en aquellos casos en que se preveaque 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 deinformacin semntica almacenada sea elevado, por lo que se recomienda la instalacin dealguno de los servidores semnticos nativos. Observando la grfica resumen puede verse quedos de ellos destacan especialmente sobre los dems: 4store y virtuoso. Si se tiene en cuenta elvolumen de datos estimados para el Portal OpenData Estatal durante los primeros aos 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 servidorsemntico. Es importante sealar que, aunque la versin Open Source gratuita de virtuosocumple ms que sobradamente con los requerimientos del Portal OpenData Estatal, existetambin una versin de cdigo cerrado con diferentes licencias que aumentan sustancialmente surendimiento (ms informacin en: http://virtuoso.openlinksw.com/pricing/).

4 Arquitectura propuesta

Se muestra a continuacin el grfico resumen que representa la arquitectura propuesta para el portal OpenData Estatal en vista a los resultados delestudio: Drupal como gestor de contenidos web y Virtuoso como servidor nativo de tecnologa semntica.

CMS Definicion

Documents

Transcript of CMS Definicion