Eduardo Benito Díez
Julio Rubio García
Máster universitario en Tecnologías Informáticas
2015-2016
Título
Director/es
Facultad
Titulación
Departamento
TRABAJO FIN DE ESTUDIOS
Curso Académico
Aplicaciones de web semántica en la Biblioteca de laUniversidad de La Rioja
Autor/es
© El autor© Universidad de La Rioja, Servicio de Publicaciones,
publicaciones.unirioja.esE-mail: [email protected]
Aplicaciones de web semántica en la Biblioteca de la Universidad de La Rioja,trabajo fin de estudios
de Eduardo Benito Díez, dirigido por Julio Rubio García (publicado por la Universidad deLa Rioja), se difunde bajo una Licencia
Creative Commons Reconocimiento-NoComercial-SinObraDerivada 3.0 Unported. Permisos que vayan más allá de lo cubierto por esta licencia pueden solicitarse a los
titulares del copyright.
Trabajo de Fin de Máster
Aplicaciones de web semántica en la Biblioteca de la
Universidad de La Rioja
Autor:
Eduardo Benito Díez
Tutor/es: Julio Jesús Rubio García
MÁSTER:
Máster en Tecnologías Informáticas (853M)
Escuela de Máster y Doctorado
AÑO ACADÉMICO: 2015/2016
1
1. Resumen ..................................................................................................... 2
2. Objetivos y plan de trabajo .......................................................................... 3
2.1 Descripción ........................................................................................... 3
2.2 Antecedentes y justificación del proyecto .............................................. 3
2.3 Alcance del proyecto ............................................................................. 3
2.4 Recursos humanos y personal .............................................................. 3
2.5 Plan de comunicaciones ....................................................................... 4
2.6 Arquitectura y tecnología ....................................................................... 4
2.7 Metodología .......................................................................................... 6
3. Análisis ........................................................................................................ 8
3.1 Identificación del entorno tecnológico ................................................... 8
3.2 Estudio de alternativas .......................................................................... 8
3.3 Establecimiento de requisitos ................................................................ 8
4. Diseño ....................................................................................................... 10
4.1 Arquitectura del sistema ...................................................................... 10
4.2 Diseño de casos de uso ...................................................................... 11
4.3 Diseño de la interfaz............................................................................ 12
4.4 Mapeado de la base de datos ............................................................. 14
5. Desarrollo .................................................................................................. 21
5.1 Implementación ................................................................................... 21
5.2 Configuración de D2R server .............................................................. 22
5.3 Personalización del explorador D2RQ ................................................ 22
5.4 Testing ................................................................................................ 24
5.5 Problemas encontrados ...................................................................... 26
6. Conclusiones ............................................................................................. 29
6.1 Mejoras ............................................................................................... 29
7. Bibliografía y referencias ........................................................................... 30
2
1. Resumen
Este trabajo fin de máster consistirá en el análisis y la implementación de un buscador semántico para la Biblioteca de la Universidad de La Rioja.
Se realizará un estudio previo de las aplicaciones y el buscador actual para
ver cómo se podría mejorar la formar de almacenar y representar los datos
para realizar un buscador facetado.
Abstract
This work will consist in the analysis and implementation of a semantic
search engine for the La Rioja University Library.
The current systems and search application will be studied in order to find
better way to storage and represents the data to develop a faceted search
engine.
3
2. Objetivos y plan de trabajo
2.1 Descripción
La idea es que toda la información disponible en la biblioteca de la
Universidad de La Rioja sobre labores de investigación se pueda publicar
como Linked data, es decir que los datos estén correctamente
estructurados y puedan ser consultados mediante consultas semánticas.
Intentaremos desarrollar dos aplicaciones, por una parte, un explorador de
los datos disponibles y por la otra un buscador facetado.
Herramientas como D2RQ nos pueden proporcionar este tipo de
exploradores, aunque será necesario personalizarla e integrarla con el
buscador.
2.2 Antecedentes y justificación del proyecto
Este trabajo se basará y compartirá la misma base de datos que la actual
aplicación de investigadores de la Biblioteca de la Universidad de La Rioja.
Se quiere analizar la viabilidad y posibles ventajas de utilizar tecnologías
semánticas sobre todo para mejorar la experiencia y los resultados del
buscador.
2.3 Alcance del proyecto
2.3.1 Estado del arte
Estudio de aplicaciones similares.
Estudio de las herramientas y lenguajes disponibles para reutilizar bases
de datos relacionales a documentos RDF como D2RQ y R2RML.
Estudio de frameworks para el desarrollo de aplicaciones semánticas como
Apache Jena o Drupal OSF.
2.3.2 Documentación necesaria
Será necesario recopilar información sobre la web semántica, Linked data,
RDF, OWL y D2RQ.
2.4 Recursos humanos y personal
Eduardo Benito: realizador del proyecto.
Decisiones a tomar: todas las decisiones, algunas de ellas discutidas
previamente con el director del proyecto.
Dedicación: completa.
4
Julio Rubio: tutor académico.
Decisiones a tomar: todas las relacionadas con la metodología a seguir,
los documentos a redactar y la forma de presentarlos.
Revisará periódicamente las entregas y se preocupará de que se cumplan
los plazos previstos.
Dedicación: esporádica.
Joaquín León: subdirector de la biblioteca de la Universidad de la Rioja.
Decisiones a tomar: las relacionadas con la especificación de requisitos y el
correcto funcionamiento de la aplicación.
Dedicación: esporádica
2.5 Plan de comunicaciones
Correo electrónico
Posiblemente será el medio más utilizado por la comodidad que supone
para los implicados en este proyecto.
Reuniones
En las primeras fases del proyecto se realizarán algunas reuniones para
establecer los requisitos iniciales y poner en común los objetivos de este
proyecto, más adelante quizás sea necesario celebrar alguna para realizar
labores de seguimiento.
2.6 Arquitectura y tecnología
2.6.1 Tecnologías disponibles
SPARQL
Es el acrónimo de Protocolo Simple y Lenguaje de Consulta de RDF.
Permite hacer consultas sobre información almacenada en formato RDF,
usando distintas fuentes de datos y permite obtener también los resultados
en formato RDF para poder reutilizarlos en las aplicaciones.
Se trata de una recomendación oficial del W3C y es una tecnología clave
en el desarrollo de la Web Semántica
5
HTML5
Es un lenguaje de marcado para crear páginas web. La versión 5 incorpora
etiquetas como header, article, section, nav o footer que nos permiten
definir mejor las partes de una web.
CSS3
Es un lenguaje para definir la apariencia de las páginas web.
Bootstrap3
Es un framework de desarrollo HTML, CSS y JavaScript para crear sitios
web con un aspecto visual correcto sin necesidad de invertir demasiado
tiempo en ello. También es muy útil para que las webs se visualicen
correctamente en todos los dispositivos.
PHP
Es acrónimo recursivo de PHP: Hypertext Preprocessor, es un lenguaje de
código abierto muy popular especialmente adecuado para el desarrollo
web. Actualmente es utilizado por muchos de los sitios de internet, gracias
a que herramientas populares como Wordpress están desarrolladas en
este lenguaje.
Silex
Es un microframework PHP, desarrollado en su mayoría con componentes
de Symfony, otro framework PHP.
Está pensado especialmente para aplicaciones sencillas y SPA (de una
sólo página). En caso de necesitar opciones más avanzadas cuenta con
varias extensiones.
Guzzle
Un cliente HTTP para PHP, facilita el trabajo de enviar y recibir peticiones
HTTP y permite integrar fácilmente servicios web.
Twig
Un motor de plantillas para PHP rápido, flexible y seguro. Está pensado
para ser usado tanto por desarrolladores como por programadores.
6
2.6.2 Tecnologías utilizadas
GIT
Un sistema de control de versiones distribuido para poder controlar los
cambios realizados. Es fundamental su uso sobre todo para trabajar
equipo, o como en este caso para trabajar en varios equipos distintos
teniendo todos los cambios sincronizados.
Vagrant
Una herramienta que permite crear entornos de desarrollo ligeros y
aislados del sistema operativo instalado en un equipo
2.6.3 Herramientas utilizadas
Codeception
Un framework de testing que permite realizar test unitarios, funcionales o
de integración de manera sencilla para proyectos PHP. Los tests pueden
ser ejecutados en un explorador estándar como chrome o firefox o
navegadores virtuales como selenium o phantomjs.
2.7 Metodología
Se seguirá una metodología adaptada a mi día a día como desarrollador,
se usará una adaptación de la metodología del tablero Kanban en el que
se irán distribuyendo las tareas a realizar o historia de usuario en varias
listas: Backlog, Next, Doing, y Done. Para las listas de Next y Doing,
existe una limitación de 3 tareas como máximo.
Para gestionar el tablero se usará la herramienta Trello.
7
2.8 Calendario
La realización del proyecto se desarrollará entre abril de 2016 y julio de
2016 (4 meses).
8
3. Análisis
3.1 Identificación del entorno tecnológico
El único hardware necesario será un ordenador portátil con el sistema
operativo Windows 64, aunque se utilizará Vagrant para trabajar sobre una
máquina virtual con Ubuntu instalado.
Como software se utilizará el IDE NetBeans y el navegador Firefox.
3.2 Estudio de alternativas
Realmente no ha habido un estudio de alternativas exhaustivo para
ninguna de las tecnologías utilizadas y más bien se han realizado la
elección por sentido común o por ser tecnologías ya conocidas.
Como sistema de base de datos se utilizará MySQL porque la aplicación
anterior ya lo usa por lo que no se plantea otra alternativa.
Se utilizará PHP como lenguaje de programación porque es el lenguaje
habitual con el que trabajo y aunque en un principio leyendo sobre la
integración que tiene D2RQ con Apache Jena y otras herramientas escritas
en Java, se planteaba como una buena opción decidí utilizar PHP.
Para el frontend se usará Bootstrap, jQuery y la librería datatables para
filtrar y ordenar los datos representados en tablas, porque también los uso
prácticamente a diario.
3.3 Establecimiento de requisitos
3.3.1 Actores
Usuario
La aplicación dispondrá de un único actor, esta es una aplicación que sólo
muestra información, las labores de administración se hacen desde otra
aplicación. Un usuario podrá navegar por la información del sistema a
través del explorador RDF o usando el buscador.
3.3.2 Casos de uso
CU.1. Explorador
CU.1.1. Listado de clases
CU.1.2. Directorio de una clase
CU.1.3. Detalle de un recurso
CU.1.4. Filtrar
9
CU.1.5. Ordenar
CU.2. Buscador
CU.2.1. Buscar en el campo de texto.
CU.2.2. Filtrar por tipo de contenido.
CU.2.3. Filtrar por facetas.
CU.2.4. Paginar
CU.2.5. Consultas predefinidas.
10
4. Diseño
4.1 Arquitectura del sistema
Explorador:
Usaremos D2RQ: la arquitectura de esta aplicación es la siguiente:
Muchos de estos componentes no son necesarios para nuestro trabajo, nos
interesa sobretodo el endpoint SPARQL que proporciona D2R Server y la
parte pública accesible desde un navegador HTML.
Buscador:
Para la aplicación del servidor usaremos solamente dos capas:
Controlador:
Esta capa se encarga de realizar las peticiones al endpoint SPARQL que
nos proporciona D2RQ. Realizará también el enrutamiento, filtrados,
redirecciones y preprocesamiento de las consultas para pasarlas a la capa
Vista con el formato adecuado.
Vista:
Capa de presentación, encargada únicamente de presentar los resultados y
filtros que nos proporciona el controlador.
11
4.2 Diseño de casos de uso
Los casos de uso del explorador son los que nos proporciona el navegador
D2RQ y no se van a analizarlos en detalle, pero serían los siguientes:
CU.1. Explorador
CU.1.1. Listado de clases
CU.1.2. Directorio de una clase
CU.1.3. Detalle de un recurso
CU.1.4. Filtrar
Esta será una funcionalidad añadida, en las tablas se podrán filtrar los
resultados en tiempo real gracias a un buscador de texto.
CU.1.5. Ordenar
Los recursos listados en la vista del directorio se podrán ordenar por
nombre de manera ascendente y descendente.
CU.2. Buscador
CU.2.1. Buscar en el campo de texto.
Se podrá realizar la búsqueda desde la página de inicio o desde propio
buscador, el campo de búsqueda se mantiene siempre visible en la parte
superior de la pantalla.
CU.2.2. Filtrar por tipo de contenido.
Los tipos de contenido de los resultados del buscador se mostrarán en
un lateral y se podrá filtrar por un tipo de contenido concreto.
CU.2.3. Filtrar por facetas.
Una vez seleccionado un tipo de contenido se podrá afinar más la
búsqueda gracias a las facetas propuestas, por ejemplo, una vez
seleccionado el tipo de contenido de trabajo académico se podrá filtrar
por año de publicación.
CU.2.4. Paginar
Sólo se mostrarán una cantidad limitada resultados en pantalla y el resto
de resultados se agruparán en diferentes páginas. Para poder navegar
por todos estará disponible un control con las páginas anterior y
siguiente y algunas de las páginas adyacentes a la actual.
12
CU.2.5. Consultas predefinidas.
Al lado del buscador se mostrarán también una serie de consultas
predefinidas de interés.
4.3 Diseño de la interfaz
Algunas de las pantallas se tratan simplemente de un rediseño de las
originales del explorador de D2RQ, siguiendo la misma línea se han
desarrollado también las del buscador.
Página de inicio:
13
Listado:
Detalle:
14
Buscador:
4.4 Mapeado de la base de datos
D2RQ Es la herramienta que nos proporciona el explorador RDF y el buscador
SPARQL a partir de una base de datos relacional. Para conseguirlo primero
debemos generar un archivo de mapping en el que se indica cómo convertir las
tablas y relaciones de la base de datos en clases y etiquetas interpretables por
el motor de D2RQ.
D2RQ incluye la herramienta generate-mapping http://d2rq.org/generate-mapping
para la generación automática del mapeado a partir de una base de datos
relacional.
Es importante que la base de datos original tenga definidas lo mejor posibles
sus claves foráneas y el tipo de dato de cada campo para que direct mapping
funcione correctamente. No obstante, se puede modificar manualmente este
archivo antes de levantar el servidor.
El proceso automáticod de mapping por defecto asigna a cada clase el nombre
de la tabla y como etiqueta para cada elemento de la clase le asigna una
etiqueta genérica tipo: “asignatura <id_asignatura>”, por lo tanto, uno de los
cambios que he tenido que realizar para cada clase ha sido asignarle un
nombre más descriptivo que comience por mayúscula, y también elegir una
15
etiqueta con más sentido para cada elemento por ejemplo en el caso anterior el
nombre de la asignatura.
Para cambiar manualmente el archivo mapping.ttl generado utilizar el lenguaje
de mapeado de D2RQ http://d2rq.org/d2rq-language.
Esquema inicial de la base de datos
La base de datos que vamos a utilizar es la que se está utilizando actualmente
en el portal URInvestiga http://investigadoresur.unirioja.es/investigadoresur/. Este
portal se realizó como parte del TFG “Reingeniería de una aplicación web
FileMaker para una biblioteca” por la alumna Nabila Anou y en él se puede
consultar el esquema detallado de esta base de datos
http://biblioteca.unirioja.es/tfe_e/R000001471.pdf (En la página 54).
En un principio partimos de un total de 26 tablas, pero no será necesario
mapear algunas de ellas como por ejemplo ULTIMA_SINCRO, que se usa
como control interno. Otras como ATESIS o INVESTIG_GRUPO_ESPEJO
sólo contienen relaciones entre varias tablas o agregan algún campo que no es
relevante para mostrar en el explorador, todas estas tablas no serán incluidas o
se fusionarán con otras.
Mapping detallado
A continuación, se detalla cuáles son las tablas incluidas en el archivo de
mapping, con los campos representados y las propiedades o relaciones
adicionales. El campo en negrita representa a la que hace las funciones de
rdf:label de esa clase.
Si no se indica nada sobre un campo se entiende que en el archivo de mapping
aparece como una propiedad estándar y se representa del siguiente modo:
map:Actividades_ISBN a d2rq:PropertyBridge; d2rq:belongsToClassMap map:Actividades; d2rq:property vocab:actividades_ISBN; d2rq:propertyDefinitionLabel "actividades_espejo ISBN"; d2rq:column "actividades_espejo.ISBN";
ACTIVIDADES
CODIGOAC DOCUMENTO ANOINICIO TIPO_ACTIVIDAD ISBN REGISTRO_COMPLETO URL_TEXTO_COMPLETO
16
URL_TEXTO_COMPLETO_TIPO URL_SCOPUS URL_ABSYS TIPO_DOCUMENTO RESUMEN TITULOAC CODIGO_IDIOMA CODIGO_PAIS ESPEJO_AÑO_JCR ESPEJO_AÑO_SJR ANIO_PARA_INRECS FASTCULO_REVISRA CODIGO_EJEMPLAR_REVISTA ISSN_SIN_GUION CODIGO_TIPO DOI VALIDADO CODIGOTESISUR CODIGOLIBROSUR CODIGOLIBROURCAPITULOS URL_IMAGEN_LIBRO REFERENCIAS CONTAR_USUARIOS_UR
INVESTIGADOR:
map:Actividades_investigador a d2rq:PropertyBridge; d2rq:belongsToClassMap map:Actividades; d2rq:property vocab:Actividades_investigador; d2rq:propertyDefinitionLabel "actividad Actividades_investigador"; d2rq:column "investigadoresactividad.nombreInvestigador"; d2rq:join "investigadoresactividad.codActividad => actividades_espejo.CODIGOAC"; d2rq:join "investigadoresactividad.dni => investigadoresactividad.DNI"
ASIGNATURA
CODIGOASIGNATURA NOMBRE_ASIGNATURA URL_ASIGNATURA
CENTRO_INVESTIGADOR
CODIGO_CENTRO NOMBRE_CENTRO NOMBRE_CENTRO_ABREVIADO TIPO_CENTRO WEB_CENTRO CODIGO_DIRECTOR URL_REGLAMENTO
17
DEPARTAMENTO
CODIGO DEPARTAMENTO NOMBREDEPARTAMENTO NOMBREDIRECTOR WEB - foaf:homepage
ESPECIALIDADES
CODIGO NUMERO NOMBRE_ESPECIALIDAD
ESPECIALIDADES_GRADOS
CDIGO_REGISTRO CODIGO_TIPO NOMBRE_ESPECIALIDAD URL_TFE
FACULTAD
CODIGO_FACULTAD NOMBRE_FACULTAD WEB_FACULTAD – foaf:homepage
GRUPO_INVESTIGACION
IDGRUPOINV DEPARTAMENTO FECHAINICIO FECHAFIN ACRONIMO DESCGRUPOINV - LABEL LINEASINVESTIGACION WEB_GRUPO - foaf:homepage NOVEDADES_BIBLIOGRAFICAS VALIDO
TRABAJOS_ACADEMICOS
CODIGO_REGISTRO FECHA_DEFENSA IDIOMA COD_ESPECIALIDAD TFE_NOMBREFICHERO TIPOTRABAJO
18
TITULO URL_TRABAJO AUTORES_NOMBRE CURSO ANO_FINALIZACION COD_TIPO_TRABAJO PFC_TITULACION MASTER_PROFESORADO_ESPECIALIDAD ESP_PFG ESPECIALIDAD map:Trabajos_academicos_especialidad a d2rq:PropertyBridge; d2rq:belongsToClassMap map:Trabajos_academicos; d2rq:property vocab:trabajos_academicos_especialidad; d2rq:propertyDefinitionLabel "trabajos_academicos especialidad"; d2rq:column "especialidades.Nombre_especialidad"; d2rq:join "especialidades.numero => trabajos_academicos.cod_especialidad";
DIRECTOR
map:Trabajos_academicos_director a d2rq:PropertyBridge; d2rq:belongsToClassMap map:Trabajos_academicos; d2rq:property vocab:trabajos_academicos_director; d2rq:propertyDefinitionLabel "Trabajos_academicos Director"; d2rq:pattern "@@trabajos_academicos_directores.apellidos@@, @@trabajos_academicos_directores.nombre@@"; d2rq:join "trabajos_academicos_directores.Id_trabajo => trabajos_academicos.codigo_registro";
TRABAJOS_ACADEMICOS_DIRECTORES
Se fusiona con TRABAJOS_ACADEMICOS mediante una propiedad, debemos
usar d2rq:pattern porque nombre y apellidos están en campos diferentes.
map:Trabajos_academicos_director a d2rq:PropertyBridge; d2rq:belongsToClassMap map:Trabajos_academicos; d2rq:property vocab:trabajos_academicos_director; d2rq:propertyDefinitionLabel "Trabajos_academicos Director"; d2rq:pattern "@@trabajos_academicos_directores.apellidos@@, @@trabajos_academicos_directores.nombre@@"; d2rq:join "trabajos_academicos_directores.Id_trabajo => trabajos_academicos.codigo_registro";
INVESTIG_GRUPO_ESPEJO
Sólo la utilizaremos para realizar un JOIN entre personas y grupos de
investigación mediante una propiedad de referencia.
map:investig_grupo_espejo_Grupo__ref a d2rq:PropertyBridge; d2rq:belongsToClassMap map:Personas;
19
d2rq:property vocab:investig_grupo_espejo_Grupo; d2rq:refersToClassMap map:grupo_investigacion; d2rq:join "investig_grupo_espejo.idGrupo => grup_inv_espejo.IDGRUPOINV"; d2rq:join "investig_grupo_espejo.dni => usuariosbur.DNI";
Vocabularios estándar
En la web semántica existen un conjunto de vocabularios comunes para
etiquetar o hacer referencia a una serie de clases o atributos comunes que
utilizamos en los archivos RDFs.
En el apartado anterior donde se especifica la estrategia de mapeado que se
utilizará en este trabajo ya han aparecido algunos de estos vocabularios y sus
atributos como por ejemplo foaf:homepage.
Estos son unos de los vocabularios estándar más populares que han sido
utilizados en el trabajo:
FOAF
FOAF es un proyecto para relacionar la información personal disponible en la
web.
Integra redes sociales de colaboración, amistad o colaboración.
DC - Dublin Core
Dublin Core es un modelo de metadatos elaborado y auspiciado por la DCMI
(Dublin Core Metadata Initiative).
Es un sistema de 15 definiciones semánticas descriptivas que pretenden
transmitir un significado semántico a las mismas.
Contenido:
DC.Title
DC.Subject
DC.Description
DC.Source
DC.Type
20
DC.Relation
DC.Coverage
Propiedad Intelectual:
DC.Creator
DC.Publisher
DC.Contributor
DC.Rights
Instanciación:
DC.Date
DC.Format
DC.Identifier
DC.Language
SKOS
Simple Knowledge Organization System (Sistema Simple de Organización del
Conocimiento) proporciona un modelo para la representación de la estructura
básica y el contenido de esquemas de conceptos. Al tratarse de una aplicación
de RDF (Resource Description Framework), SKOS permite la creación y
publicación de conceptos en la Web, así como vincularlos con datos en este
mismo medio e incluso integrarlos en otros esquemas de conceptos.
En el uso básico de SKOS, los recursos conceptuales (conceptos) pueden ser
identificados con URIs, etiquetados con cadenas léxicas en una o más lenguas
naturales, documentados con diversos tipos de nota, relacionarse
semánticamente entre sí mediante estructuras jerárquicas informales y redes
de asociación y agruparse en esquemas de conceptos.
21
5. Desarrollo
5.1 Implementación
La parte más interesante del desarrollo de la aplicación es saber cómo se
realizan las consultas desde PHP al endpoint SPARQL.
Vamos a analizar el ejemplo para una de las consultas predefinidas, pero sería
similar para la obtención de resultados o el conteo de los filtros, solamente con
cambiar la consulta SPARQL.
1. Generamos o recuperamos la query SPARQL
$query = $app['prefixes'] . 'SELECT ?name (count(distinct ?a) as ?count)' . ' WHERE {' . ' ?a vocab:actividades_anoinicio ?name' . ' }' . 'group by ?name order by DESC(?count)'; break; }
2. Se crea un cliente de Guzzle con el que realizaremos la peticiones
use GuzzleHttp\Client; $client = new Client([ 'base_uri' => 'http://localhost:2020/sparql', 'timeout' => 30.0, // 30 segundos ]);
3. Realizamos la consulta y los resultados los almacenamos en una
variable que pasamos a la plantilla twig para que los muestre.
$consulta['rows'] = doConsulta($client, $query); $params['consulta'] = $consulta; return $app['twig']->render('index.html.twig', $params);
4. Para hacer la consulta mandamos una petición al endpoint y se obtiene
la respuesta en formato json, este json se formatea y se procesa según
el tipo de consulta, en este caso obtenemos para cada resultado las
variables “name” y “count”
22
function doConsulta($client, $query) { $response = $client->request('POST', 'http://localhost:2020/sparql', [ 'form_params' => [ 'query' => $query, 'output' => 'json' ] ]); $body = (string) $response->getBody(); $json_response = json_decode($body); $rows = array_map(function($binding) { return array( "name" => $binding->name->value, "count" => $binding->count->value); }, $json_response->results->bindings); return $rows; }
5.2 Configuración de D2R server
Por defecto el servidor de d2r está limitado a 50 resultados por clase, para
poder navegar por todas las instancias debemos añadir un bloque de código de
configuración al archivo de mapping:
<> a d2r:Server; d2r:limitPerClassMap false;
También contamos con la limitación por defecto de 50 propiedades para cada
una de las clases, igualmente podemos eliminar esta limitación añadiendo la
línea:
d2r:limitPerPropertyBridge false;
5.3 Personalización del explorador D2RQ
Lamentablemente este explorador a pesar de ser una excelente herramienta,
cuenta con la desventaja de no haber sido actualizado en los últimos años, por
ello su diseño deja bastante que desear respecto a los estándares actuales de
la web.
Sin querer invertir demasiado tiempo en esta tarea, he intentado modificar su
código para contar con un aspecto más adecuado. Esta aplicación utiliza para
su capa de presentación plantillas de Apache Velocity
(http://velocity.apache.org/engine/1.7/webapps.html), y afortunadamente
podemos modificar estas plantillas sin necesidad de recompilar el proyecto y
los cambios se reflejan de inmediato en el navegador.
Estas son algunas capturas con el diseño original:
23
Directorio:
Detalle:
Y éstas con el diseño final:
Directorio:
24
Detalle:
5.4 Testing
Con la herramienta codeception y phantomjs se han realizado un conjunto de
test de aceptación para comprobar que el buscador funciona correctamente.
La instalación de esta herramienta es muy sencilla si usamos composer:
"require-dev": { "codeception/codeception": "*" }
Módulos
El módulo Recorder permite hacer una captura de pantalla de cada paso, y
posteriormente en caso de error podemos conocer exactamente el estado de la
aplicación cuando falló:
extensions: enabled: - Codeception\Extension\Recorder config: Codeception\Extension\Recorder: delete_successful: false
El primer paso es generar el archivo codeception.xml y la carpeta de tests se
ejecuta:
./vendor/bin/codecept bootstrap
Se incluye un único archivo de test unitarios:
25
<?php $I = new AcceptanceTester($scenario); $I->wantTo('Probar el buscador'); $I->amOnPage('http://localhost:80/buscador/web/'); $I->fillField("input[name='q']", 'Rubio García, Julio'); $I->click('#btn-buscar'); // Filtro de tipo de contenido $I->see('TRABAJOS_ACADEMICOS','.filtro'); $I->see('32','.badge'); $I->see('PERSONA','.filtro'); $I->see('1','.badge'); // Total de resultados $I->see('33 resultados'); // Resultados concretos antes y después de páginar $I->see('Lispspaces'); $I->click('Siguiente'); $I->see('Asistente web para consultas SQL'); // Selecciono el filtro de tipo trabajo academico $I->click('a.filtro:nth-child(1)'); $I->see('32 resultados'); $I->see('Instalador configurable a través de ficheros XML'); // Deselecciono el filtro de tipo $I->click('.tipo a'); // Selecciono el filtro de tipo persona $I->click('a.filtro:nth-child(2)'); $I->see('1 resultados'); $I->see('Rubio García, Julio');
Cómo se puede ver el código utilizado en codeception es bastante descriptivo. Para pasar los tests se ejecuta la instrucción:
./vendor/bin/codecept run acceptance
Si todo ha ido bien obtenemos un mensaje de este tipo:
26
5.5 Problemas encontrados
Un problema Problema SPARQL
Problema con los totales facetados.
La consulta que devuelve los resultados que se muestran en el listados del
buscador:
SELECT (count(distinct ?s) as ?c) WHERE { ?s ?p "1990". ?s rdfs:label ?label. ?s rdf:type ?type}
Nos estaba devolviendo 45 filas, mientras que la consulta para recuperar el
número de recursos con esas condiciones:
SELECT ?value (count(?value) as ?c) WHERE {?s vocab:trabajos_academicos_TipoTrabajo ?value. ?s ?p "1990". ?s rdfs:label ?label. ?s rdf:type ?type. ?s vocab:trabajos_academicos_ano_finalizacion ?trabajos_academicos_ano_finalizacion} group by ?value
Estaba devolviendo 65 filas.
Cuando hay más de una propiedad que cumple la primera condición (?s ?p
"1990") vamos a obtener más resultados de los totales esperados.
Esto se soluciona haciendo dentro del count un distinct ?s, y
afortunadamente con SPARQL no hay ningún problema aunque no
hayamos agrupado por la variable ?s.
SELECT ?value (count(distinct ?s) as ?c) WHERE {?s vocab:trabajos_academicos_TipoTrabajo ?value. ?s ?p "1990". ?s rdfs:label ?label. ?s rdf:type ?type. ?s vocab:trabajos_academicos_ano_finalizacion ?trabajos_academicos_ano_finalizacion} group by ?value
Ahora la consulta sí que devuelve 45 filas, como era la esperado.
27
Problemas con los filtros:
Un problema que ha sido difícil de solucionar ha sido manejar las
dependencias entre los filtros facetados. En un principio estaba mostrando
los totales de cada valor sin tener en cuentos los filtros que ya habían sido
seleccionados, por lo que los valores mostrados eran mucho más altos. Al
intentar hacer frente a este problema de conteo para los valores facetados
surgió otro que afectaba más todavía al funcionamiento del buscador.
Partiendo de una situación cómo está en el buscador:
Cuando se seleccionaba un filtro afectaba de tal manera a las consultas de
los valores facetados que ya no se podía filtrar por otro valor de la misma
categoría, y resultaba imposible por ejemplo seleccionar los trabajos
académicos de 2005 y 2006.
28
Finalmente calculando los filtros por separado para la consulta de
resultados y para cada uno de los grupos facetados (no incluyendo los
filtros de su propio grupo) se ha obtenido el comportamiento deseado
29
6. Conclusiones
Aunque al principio las tecnologías utilizadas con la web semántica me
parecían bastante complicadas en comparación con las tecnologías
habituales en el desarrollo web, sobre todo el lenguaje de consultas
SPARQL. Al final me he encontrado bastante cómodo trabajando con él y
me ha parecido muy potente a la hora de hacer consultas relacionadas y
agrupadas y de una manera más sencilla que con SQL.
6.1 Mejoras
Rendimiento
El reutilizar la base de datos existente tiene su contrapartida en el
rendimiento de la aplicación, y algunas de las búsquedas que recuperan
varias relaciones pueden tardar varios segundos.
Filtros facetados
Para no complicar demasiado la aplicación del buscador se decidió
establecer los filtros facetados directamente en código. Lo ideal será que en
propio archivo de mapping indicásemos cuáles de las propiedades de una
clase son aptas para el filtrado posterior.
Vocabulario común
Cómo ya se ha hablado en la introducción cuando todo el mundo usa los
mismos términos para referirse a los mismos productos o conceptos en
general las posibilidades de interacción entre los sistemas se multiplican.
Por ello hubiese sido ideal en lugar de utilizar nuestro propio vocabulario
condicionado por los campos existentes en la base de datos, haber
utilizado un vocabulario común para investigaciones, tesis, trabajos fin de
carrera, etc.
30
7. Bibliografía y referencias
[1] The Semantic Web, Linked Data and Drupal, Part 1: Expose your data using
RDF, http://www.ibm.com/developerworks/library/wa-rdf/
[2] A Direct Mapping of Relational Data to RDF, https://www.w3.org/TR/rdb-
direct-mapping/ [3] The D2RQ Platform - Accessing Relational Databases
as Virtual RDF Graphs, http://d2rq.org [4] Linked Data - Connect Distributed Data across the Web,
http://linkeddata.org/
