Evolución de DATEX II a un modelo semántico

Transcripción

UNIVERSIDAD DE VALENCIA
DEPARTAMENTO DE INFORMÁTICA
Trabajo de Investigación
David Torres Garrigós
Tutor
José Javier Samper Zapater
Septiembre 2009
A mis abuelos
AGRADECIMIENTOS
A mi familia, en especial a mis padres, por su apoyo, no solo por este proyecto, sino porque gracias a
ellos he podido recorrer el camino que me ha traído hasta aquí.
También agradecer a mi novia su paciencia por aguantarme los días de más trabajo y por estar ahí
conmigo en los momentos difíciles.
A mis amigos de siempre, nos vemos poco pero intensamente.
Tampoco me puedo olvidar de mis compañeros de trabajo, los (la) de la pecera, los que están pero lejos,
los que ya se fueron, el del zulo y de mis nuevos compañeros de despacho.
A Juanjo y sobre todo a mi tutor Javier Samper por guiarme en este trabajo, y en general a todo el grupo
LISITT y el Instituto de Robótica.
Gracias a todos. David.
Parece ser que Alicia encontró
algo más detrás del espejo…
RESUMEN
El dominio del tráfico ha sufrido desde su aparición una gran evolución, aprovechando para ello los
avances registrados en una gran cantidad de áreas de conocimiento relacionadas. En especial, la
aplicación de las tecnologías de la información a este campo, conocidas como sistemas inteligentes
aplicados al transporte o ITS, ha propiciado en las últimas décadas una mejora sustancial en la gestión
de la información de tráfico. Sin embargo, la complejidad inherente a esta área de trabajo, conlleva la
aparición de problemas que requieren profundos estudios para su resolución.
Uno de estos problemas es la representación del conocimiento de la información de tráfico para su
gestión y posterior explotación. Aunque existen en la actualidad numerosos sistemas propietarios
destinados a este cometido, ninguno de ellos puede ser utilizado más allá del ámbito específico para el
que se ha diseñado, sean entidades privadas o administraciones de tráfico de países o regiones. En ese
sentido, DATEX I y el recientemente aparecido DATEX II, se muestran como métodos eficaces de
intercambio de información entre sistemas heterogéneos. Sin embargo, su diseño eminentemente
práctico no facilita la explotación de la información que codifica, ofreciendo una descripción eficiente
pero demasiado básica de los datos representados.
La semántica es una vieja idea mediante la cual se expresa la información existente sobre un dominio.
En los últimos años, esta visión ha sido reinventada mediante su aproximación a la representación del
conocimiento, obteniendo aplicaciones directas tales como la Web Semántica, llamada a substituir la
Web de la actualidad y que, aplicada al dominio del tráfico, será el objeto principal del presente estudio.
Uno de las partes del trabajo será por lo tanto una revisión sobre los últimos adelantos en la Web
Semántica, en especial aquellos relacionados con el dominio del trabajo.
Otra de las piedras angulares de la presente investigación será el consumidor de la información de
tráfico. Uno de los objetivos recurrentes para los ITS es facilitar la gestión de información y la
publicación de la misma a los usuarios finales de este tipo de sistemas, sean gestores de tráfico,
analistas o los propios conductores. Mantener a estos usuarios informados redunda en un incremento
de la seguridad vial (tal como indicaba el subdirector de Circulación del Ministerio del Interior de
España, Jesús Díez de Ulzurrun, “un conductor informado es un conductor mucho más seguro”). Además,
la información ayuda a gestionar eficientemente los recursos, minimizando de esta forma los tiempos
de viaje y como consecuencia directa de ello el impacto económico y sobre el medio ambiente que se
produce en cada desplazamiento de un vehículo.
En el presente trabajo se construye una ontología de tráfico basada en DATEX II, estableciendo de esta
forma una base para abordar la problemática de la gestión de información de tráfico. Por otra parte, se
diseña una plataforma de publicación de información semántica basada en perfiles de usuarios, que
tiene como idea fundaméntela la expresión de preferencias de usuarios para adecuar la extracción de
información a las necesidades de cada perfil. De esta forma cada usuario obtiene una vista
personalizada de la información del sistema, mejorando el rendimiento que obtiene del mismo.
Se muestra además la posibilidad de integración de la ontología DATEX II dentro de esta plataforma de
publicación, efectuando experimentos de clasificación de mensajes en base a la definición de perfiles
habituales en el campo del tráfico, y obteniendo resultados que empujan a la implementación de este
tipo de sistemas en éste y otros dominios. El siguiente paso consistirá en el desarrollo de herramientas
inteligentes que consigan explotar la información de tráfico mediante transformaciones, filtrados y
ordenaciones avanzadas, que actualmente supondrían un coste de desarrollo muy elevado.
VII
TABLA DE CONTENIDO
1
JUSTIFICACIÓN...........................................................................................................................15
1.1
PLANTEAMIENTO INICIAL ................................................................................................................... 15
1.2
MOTIVACIONES Y NECESIDADES .......................................................................................................... 16
1.3
PREGUNTAS DE INVESTIGACIÓN .......................................................................................................... 17
1.4
OBJETIVOS ..................................................................................................................................... 18
1.4.1
Objetivo general ................................................................................................................. 18
1.4.2
Objetivos específicos ........................................................................................................... 18
1.5
MATERIALES UTILIZADOS ................................................................................................................... 19
1.6
ORGANIZACIÓN DE LA MEMORIA......................................................................................................... 20
2
ESTADO DEL ARTE ......................................................................................................................21
2.1
REPRESENTACIÓN DEL CONOCIMIENTO ................................................................................................. 21
2.1.1
Conceptos generales ........................................................................................................... 21
2.1.2
Ontologías .......................................................................................................................... 22
2.1.3
Web Semántica ................................................................................................................... 23
2.2
SISTEMAS INTELIGENTES DE TRANSPORTE ............................................................................................. 38
2.2.1
Servicios en ITS.................................................................................................................... 39
2.2.2
Estándares DATEX............................................................................................................... 41
2.3
APLICACIÓN DE LA WEB SEMÁNTICA A LOS ITS ....................................................................................... 45
2.4
MODELIZACIÓN SEMÁNTICA DE USUARIOS ............................................................................................ 46
2.5
SISTEMAS DE ADQUISICIÓN DE INFORMACIÓN SEMÁNTICA........................................................................ 47
3
SEMÁNTICA APLICADA A DATEX II ..............................................................................................49
3.1
3.2
3.3
4
ACTUALIZACIÓN DE LA ONTOLOGÍA DATEX II........................................................................................ 49
PROTOTIPO DE PASARELA DATEX II – DATEX II SEMÁNTICO .................................................................. 52
GENERACIÓN DE CONSULTAS.............................................................................................................. 53
PLATAFORMA DE PUBLICACIÓN .................................................................................................55
4.1
ARQUITECTURA PARA LA PUBLICACIÓN DE INFORMACIÓN SEMÁNTICA BASADA EN PERFILES ............................ 55
4.2
PERFILES DE EXPLOTACIÓN DE INFORMACIÓN DE TRÁFICO ........................................................................ 58
4.2.1
Especificación de parámetros ............................................................................................. 58
4.2.2
Definición de perfiles .......................................................................................................... 68
4.2.3
Determinación de reglas ..................................................................................................... 69
5
RESULTADOS Y DISCUSIÓN.........................................................................................................71
5.1
ONTOLOGÍA ................................................................................................................................... 71
5.2
EVALUACIÓN DEL MODELO SEMÁNTICO ................................................................................................ 72
5.2.1
Evaluación de la pasarela ................................................................................................... 72
5.2.2
Evaluación de las consultas ................................................................................................ 75
5.3
VISUALIZACIÓN DE INFORMACIÓN ....................................................................................................... 87
5.4
DISCRIMINACIÓN DE MENSAJES EN BASE A PERFILES ................................................................................ 88
6
CONCLUSIONES..........................................................................................................................91
7
TRABAJO FUTURO......................................................................................................................95
IX
GLOSARIO DE TÉRMINOS...................................................................................................................97
BIBLIOGRAFÍA ...................................................................................................................................99
ANEXO I
I.1
I.2
I.3
DATEX II ....................................................................................................................... 107
MODELO DE DATOS........................................................................................................................ 107
MODELO DE INTERCAMBIO .............................................................................................................. 108
HERRAMIENTA DTX2 ..................................................................................................................... 108
ANEXO II
II.1
II.2
II.3
II.4
LÓGICA DIFUSA APLICADA A ONTOLOGÍAS.................................................................... 111
CONJUNTOS Y LÓGICA DIFUSA .......................................................................................................... 111
VARIABLES LINGÜÍSTICAS ................................................................................................................. 112
SISTEMAS BASADOS EN REGLAS ......................................................................................................... 113
LÓGICA DIFUSA EN ONTOLOGÍAS ....................................................................................................... 114
ANEXO III
III.1
III.2
III.3
III.4
III.5
III.6
III.7
CONSULTA Q1: ESCENARIOS............................................................................................................ 115
CONSULTA Q2: SITUACIONES........................................................................................................... 115
CONSULTA Q3: SITUACIONES RECIENTES ............................................................................................ 115
CONSULTA Q4: SITUACIONES POR TIPO.............................................................................................. 116
CONSULTA Q5: ACCIDENTES CON OBJETOS PELIGROSOS ........................................................................ 116
CONSULTA Q6: SITUACIONES DENTRO DE RANGO ALERT-C .................................................................... 116
CONSULTA Q7: SITUACIONES RELACIONADAS (CONTINUIDAD) ................................................................ 116
ANEXO IV
IV.1
IV.2
IV.3
DEFINICIÓN DE CONSULTAS ...................................................................................... 115
RECURSOS DISPONIBLES ........................................................................................... 117
WEBPROTÉGÉ............................................................................................................................... 117
JOSEKI ......................................................................................................................................... 117
TABULATOR .................................................................................................................................. 118
X
ÍNDICE DE FIGURAS
Figura 1: Ejemplos de jerarquías (Biolchini, Mian, Natali, Conte, & Travassos, 2007) ............................... 23
Figura 2: Estructura en capas de la Web Semántica (W3C - Semantic Web Working Group, 2009).......... 25
Figura 3: Diagrama de Venn de los perfiles de OWL 2 (W3C - OWL Working Group, 2009) ..................... 29
Figura 4: Convención en la notación de expresividad DL (Wikipedia, 2009) .............................................. 30
Figura 5: Comparativa entre los servicios Web actuales y los SWS. Adaptada desde (Fensel & Bussler,
2002)........................................................................................................................................................... 32
Figura 6: Proceso general de conexión a un servicio Web (W3C Working Group, 2004)........................... 33
Figura 7: Definición semántica del servicio (OWL-S Coalition, 2008) ......................................................... 34
Figura 8: Descripción semántica de los perfiles de acceso a un servicio (OWL-S Coalition, 2008) ............ 35
Figura 9: Descripción semántica de los procesos asociados a la invocación de un servicio (OWL-S
Coalition, 2008) .......................................................................................................................................... 35
Figura 10: Captura de pantalla de Protégé 4 con la ontología Pizza (protégé team, 2009) ....................... 37
Figura 11: Aplicación etraffic, disponible en http://www.dgt.es (DGT, 2009) ........................................... 40
Figura 12: Arquitectura de un servicio RDS-TMC (Torres Garrigós, 2007) ................................................. 41
Figura 13: Ejemplo de navegador GPS con soporte RDS-TMC (Via Michelin, 2006) .................................. 41
Figura 14: Intercambio vía DATEX entre sistemas heterogéneos de información de tráfico ..................... 42
Figura 15: Escenario futuro de interconexión de nodos DATEX II en España............................................. 43
Figura 16: Ejemplo de retención representada mediante DATEX II ........................................................... 44
Figura 17: Jerarquía para la clase general Situation (3 niveles) ................................................................. 50
Figura 18: Jerarquía para la clase Accident................................................................................................. 51
Figura 19: Captura de la ontología DATEX II cargada en Protégé 4 ............................................................ 51
Figura 20: Ejemplo de propiedades y tipos generados mediante schemagen ........................................... 52
Figura 21: Entorno de trabajo basado en Eclipse para el desarrollo de la pasarela de DATEX II al modelo
ontológico................................................................................................................................................... 53
Figura 22: Arquitectura funcional para la explotación de información semántica basada en perfiles ...... 56
Figura 23: Modelo para la ontología Resources ......................................................................................... 58
Figura 24: Modelo para la ontología Services............................................................................................. 59
XI
Figura 25: Modelo para la ontología Translation Directory........................................................................ 59
Figura 26: Modelo para la ontología Characteristics .................................................................................. 61
Figura 27: Modelo para la ontología Context ............................................................................................. 61
Figura 28: Modelo para la ontología Concepts ........................................................................................... 62
Figura 29: Funciones de pertenencia para las etiquetas lingüísticas de la variable Distancia ................... 63
Figura 30: Funciones de pertenencia para las etiquetas lingüísticas de la variable Validez ...................... 64
Figura 31: Funciones de pertenencia para las etiquetas lingüísticas de la variable Prioridad ................... 65
Figura 32: Modelo para la ontología Preferences....................................................................................... 66
Figura 33: Funciones de pertenencia para las etiquetas lingüísticas de la variable Importancia .............. 67
Figura 34: Comparación del tamaño en memoria utilizado por los diferentes tipos de datos .................. 74
Figura 35: Comparación entre las tripletas RDF generadas con y sin el modelo de datos adjunto ........... 75
Figura 36: Evaluación de la complejidad de las consultas desarrolladas ................................................... 77
Figura 37: Eficiencia de ejecución para la consulta Q1 .............................................................................. 79
Figura 38: Eficiencia de ejecución para la consulta Q2 .............................................................................. 80
Figura 39: Eficiencia de la ejecución para la consulta Q3 ........................................................................... 81
Figura 44: Consulta SPARQL para la extracción de resultados representables sobre Tabulator ............... 87
Figura 45: Representación tabular del resultado de una consulta SPARQL sobre Tabulator..................... 87
Figura 46: Representación gráfica sobre un mapa del resultado de una consulta SPARQL sobre Tabulator
.................................................................................................................................................................... 88
Figura 47: Tipos de publicaciones según DATEX II.................................................................................... 107
Figura 48: Arquitectura lógica de la aplicación Herramienta DTX2 .......................................................... 109
Figura 49: Capturas de pantalla de la herramienta de administración de la aplicación Herramienta DTX2
.................................................................................................................................................................. 109
Figura 50: Ejemplo de representación gráfica de la función de pertenencia "Temperatura Alta" (Galindo
Gómez, 2009) ........................................................................................................................................... 111
Figura 51: Ejemplo de variable lingüística "Edad" (Oporto Díaz, 2005) ................................................... 112
XII
Figura 52: Ejemplo de modificadores lingüísticos de concentración y dilatación para una etiqueta L .... 113
Figura 53: Vista de la utilidad WebProtégé para la clase Accident ........................................................... 117
Figura 54: Formulario de entrada de consultas SPARQL de Joseki ........................................................... 118
Figura 55: Resultados de una consulta SPARQL en Joseki ........................................................................ 118
Figura 56: Vista general de Tabulator, navegador semántico .................................................................. 119
ÍNDICE DE TABLAS
Tabla 1: Relación de perfiles de clientes de información de tráfico........................................................... 69
Tabla 2: Índices de complejidad según API de acceso a información ontológica ....................................... 76
Tabla 3: Cuadro resumen de las características de la batería de mensajes elegida................................... 88
Tabla 4: Valores obtenidos para la variable lingüística distancia ............................................................... 89
Tabla 5: Valores obtenidos para la variable lingüística validez .................................................................. 89
Tabla 6: Aplicación de reglas a mensajes para perfiles de tráfico .............................................................. 89
Tabla 7: Determinación de importancia de mensajes para los perfiles de información de tráfico ............ 90
Tabla 8: Listado ordenado de mensajes por perfil ..................................................................................... 90
Tabla 9: Comparativa entre modelos de intercambio vía DATEX II .......................................................... 108
XIII
1. Justificación
1
JUSTIFICACIÓN
En este primer capítulo se va a realizar una introducción al presente proyecto de investigación,
indicando qué ha motivado su aparición y el entorno en el cual se va a desarrollar.
Además, se plantean unas preguntas de investigación que deberán resolverse durante la realización del
proyecto y que darán lugar al establecimiento de los objetivos que desean abordarse. Por último se
comentan los materiales de los que se dispone para la ejecución del proyecto.
Durante el transcurso de este apartado es posible que aparezcan términos comunes en el dominio del
tráfico desconocidos para el lector. Aunque en el estado del arte se comentará en mayor detalle algunos
de estos términos, para obtener una referencia rápida del término siempre resulta recomendable
consultar el glosario del trabajo.
1.1
PLANTEAMIENTO INICIAL
Una de las áreas que más se han visto
beneficiadas de los avances tecnológicos
de los últimos años es el tráfico. No hay
que olvidar que hace únicamente un siglo
se estaba todavía comenzando a producir
automóviles en la cadena de montaje y
que las velocidades medias de los
ganadores de los grandes premios de la
actual Fórmula 1 no llegaban a una
tercera parte de las actuales.
Desde entonces, los avances surgidos en el mundo del automóvil han traído problemas inesperados
para la ciencia y la ingeniería. Campos tan dispares como ingeniería civil, física, matemáticas o ciencias
de la computación, han hecho que el dominio del tráfico haya ocupado una considerable porción de las
investigaciones realizadas recientemente. En muchos casos, es necesaria la creación de grupos
multidisciplinares para poder atacar desde todas las vertientes los problemas que van apareciendo.
En el ámbito de las ciencias de la computación, ha surgido una importante necesidad de mejorar
tecnológicamente muchos de los sistemas destinados a incrementar la seguridad de los conductores y
de facilitar la gestión de la ingente información generada a los centros de gestión de tráfico (CGTs). Una
técnica comúnmente utilizada en estas lides es la construcción de modelos, necesaria para simplificar la
enorme cantidad de variables que suelen aparecen en cualquier problema relacionado con el tráfico.
Uno de los grupos dedicados a este cometido es LISITT (Laboratorio de Sistemas Integrado de Sistemas
Inteligentes y Tecnologías de la Información de Tráfico), que es un grupo de investigación
multidisciplinar perteneciente al Instituto de Robótica de la Universidad de Valencia. En el seno de este
grupo se participa, a través de administraciones públicas y entidades privadas, en proyectos de I+D. Las
actividades más comunes desempeñadas por el grupo son la elaboración de estudios sobre tráfico y el
desarrollo de aplicaciones informáticas orientadas a mejorar la gestión de la información por parte de
los CGTs. Estas aplicaciones comparten tanto una perspectiva de desarrollo de ingeniería clásica
(diseños de bases de datos, aplicaciones verticales) como una perspectiva de avance tecnológico,
centrándose en aplicaciones web o aplicaciones basadas en dispositivos móviles.
El presente proyecto se va a focalizar en la aplicación de las ciencias de la computación a la gestión de
información de tráfico, siguiendo una línea de investigación que considera que esta información de
15
tráfico, más allá de un simple repositorio o almacén, se puede interpretar directamente como
conocimiento. Desde esta interpretación, resulta más sencillo trabajar y explotar estos datos de tráfico,
permitiendo así la generación de aplicaciones que interactúen entre sí y con otras personas, y que
acaben finalmente consiguiendo una mejora palpable en la gestión final de la información.
1.2
MOTIVACIONES Y NECESIDADES
Dentro del grupo de trabajo LISITT el autor del presente trabajo ha participado en proyectos europeos,
centrados en la difusión e intercambio de información de tráfico entre entidades públicas. En concreto,
se pueden citar las siguientes actividades:
•
Desarrollo y mantenimiento de Servidores RDS-TMC (Dirección General de Tráfico de España y
Administració de Mobilitat en Andorra).
•
Participación en representación de España en el Technical Committee Group de DATEX II, grupo
técnico encargado de definir el modelo de datos y de intercambio del modelo DATEX II.
•
Desarrollo de una plataforma de servicios web de intercambio de información de tráfico vía DATEX
II (ver Anexo I, apartado I.3).
La experiencia personal del autor es que estos sistemas de difusión e intercambio son eminentemente
prácticos, y han sido diseñados buscando la mayor sencillez posible de cara a sus aplicaciones técnicas.
Sin embargo, en ciertos casos esta sencillez en su diseño dificulta que otros sistemas externos puedan
explotar la información con la que trabajan.
En concreto, las dificultades más comunes que aparecen en el desarrollo de este tipo de sistemas
externos suelen ser las siguientes:
•
•
Pérdida de información en la creación de pasarelas entre sistemas: Al establecer una pasarela
entre un sistema de difusión o intercambio y el sistema propietario de la administración pública o
empresa, es necesario siempre efectuar una traducción entre los dos modelos de datos implicados.
En función de la disparidad entre ambos modelos, esta pérdida de información podrá ser más o
menos notable. Se ha observado que estos problemas se producen principalmente a los siguientes
tres niveles:
o
Nivel lógico: Muchas veces la organización lógica de la información del sistema propietario
difiere del sistema estándar.
o
Diccionarios de datos: Normalmente los sistemas adecuan sus diccionarios en base a sus
necesidades, por lo que sistemas comunes podrían diferir en gran medida a los diccionarios
de datos propietarios.
o
Localizaciones: Los sistemas de localización pueden ser muy distintos, lo cual provoca que,
en la traducción, se pierda precisión en la localización de eventos.
Elaboración de plataformas completas de filtrado: Aunque sí que es posible efectuar métodos de
filtrado de información sencillos, cuando el filtrado adquiere cierta complejidad en número de
variables o dificultad del concepto de filtrado, el desarrollo de este tipo de métodos se vuelve muy
complicado. Es muy difícil modelar, diseñar y desarrollar peticiones de usuarios provenientes del
lenguaje natural, como por ejemplo: “Quiero los eventos de tráfico que estén cerca de mi posición”
o “sólo me interesan aquellos eventos realmente importantes”. En estos casos, inabordables desde
la perspectiva actual, resultaría necesario modelizar perfectamente las peticiones del usuario, y
tener disponible metainformación para poder realizar inferencia sobre la información de tráfico
16
1. Justificación
(p.ej. discriminar eventos que son importantes de los que no lo son, teniendo en cuenta que el
concepto “importante” posiblemente será distinto para cada usuario del sistema).
Debido a estos motivos, parecería interesante disponer de un formato que actuara como una base real
de conocimiento en lugar de un conjunto de datos. A partir de ahí, sería posible elaborar aplicaciones
que explotaran la información de tráfico desde un punto de vista semántico, pudiendo efectuar
razonamientos lógicos para obtener respuestas a partir de los datos de los que se dispone, y que
pudieran ajustarse en mayor medida a los requerimientos de los usuarios.
Llegado este punto, parece razonable pensar que parece necesaria una herramienta para la descripción
de conocimiento que ayude a representar el conocimiento existente en el dominio del tráfico. Aunque
existen distintos métodos de representación de conocimiento uno de ellos está tomando un especial
auge en los últimos años: la Web Semántica.
En LISITT se ha avanzado en esta línea, principalmente debido a los trabajos de José Javier Samper
Zapater, que culminaron en la lectura de su tesis (Samper Zapater J. J., 2005). En ella se utiliza las nuevas
tecnologías que ofrece la Web Semántica para construir una base de conocimiento (ontología) que
permite trabajar en el dominio del tráfico, construyendo además una infraestructura de servicios para
explotar esta información. Otra tesis leída en el mismo departamento y que sigue la misma línea fue
(Tomás López, 2006), en este caso centrada en la implementación de planes de gestión de tráfico.
Otro trabajo relacionado con esta línea de investigación fue el realizado por David Canós Gandía en el
proyecto (Canós Gandía, 2003), así como la publicación relacionada (Samper Zapater, Adell, García
Calderario, Martínez Durá, & Vidal Peña, 2009). En estos trabajos, se propone construir a partir del
estándar de modelo de datos tráfico DATEX II, otra ontología de representación de información de
tráfico. Utilizando esta ontología se construyen algunas aplicaciones de prueba que trabajan
directamente con información semántica, obteniendo buenos resultados.
En base a las carencias señaladas en los sistemas de difusión e intercambio de información, parece
recomendable continuar esta línea de investigación abierta, con lo que se podrían conseguir a priori
resultados muy interesantes.
1.3
PREGUNTAS DE INVESTIGACIÓN
Aunque el panorama empuja a la consideración de DATEX II como representación del conocimiento en
forma de ontología, es necesario preguntarse si esta sigue siendo la mejor opción, y en el caso de que lo
sea, obtener una justificación de ello:
•
¿Es DATEX II una base adecuada para la creación de una ontología que represente el conocimiento
existente en el dominio de tráfico? ¿Qué modificaciones es necesario realizar en el modelo para
adaptarlo a este cometido?
•
El paso a una infraestructura basada en el conocimiento aporta sin duda complejidad al modelo
general. ¿Qué mejoras aporta el uso de un modelo semántico sobre un modelo clásico? ¿Podrá ser
el modelo resultante interoperable entre los sistemas ya existentes?
Otras preguntas que servirán como base de la investigación que se pretende realizar son las siguientes:
•
¿Siguen ofreciendo las ontologías una representación del conocimiento adecuada? ¿Qué formatos y
herramientas de representación son los más apropiados en la actualidad?
•
¿Es posible asegurar un marco de referencia que permita la explotación de la información de forma
semántica en forma de aplicaciones inteligentes?
17
•
1.4
En base a los resultados obtenidos, ¿es posible la generalización de los experimentos y resultados
obtenidos para la extracción de conclusiones aplicables a otros dominios?
OBJETIVOS
Después de haber esbozado el inicio del proyecto, en este apartado se comentan los objetivos que se
van a plantear como meta para la resolución de las preguntas de investigación lanzadas en el apartado
anterior.
1.4.1 OBJETIVO GENERAL
El objetivo principal del presente proyecto de investigación es la evolución de DATEX II a un modelo
semántico. La idea general es poder fundar las bases de un modelo de datos de tráfico que permita la
explotación de datos de forma inteligente, pero siempre conservando la naturaleza práctica para la cual
se ha diseñado; se pretende por tanto un formato que facilite su utilización e integración en sistemas ya
existentes.
Una vez conseguido este punto de partida, será posible apoyarse en este modelo para abrir nuevas
líneas de trabajo basadas en aplicaciones que utilicen el razonamiento para ofrecer una nueva
perspectiva a algunas aplicaciones complejas.
1.4.2 OBJETIVOS ESPECÍFICOS
Para llevar a cabo el objetivo general del proyecto, se ha efectuado una primera división en tareas, que
ofrecerá los objetivos específicos que se desean conseguir:
•
Revisión bibliográfica sobre la Web Semántica: El campo de la Web Semántica es relativamente
novedoso. Desde que Tim Berners-Lee sentara las bases de este nuevo enfoque de la Web (BernersLee, Hendler, & Lassila, The Semantic Web: A new form of Web content that is meaningful to
computers will unleash a revolution of new possibilities, 2001), han aparecido multitud de artículos,
investigaciones y proyectos sobre esta nueva tecnología. Se pretende realizar una recopilación,
selección y análisis de todo este material, para formar una idea concreta y actualizada de la
investigación en este terreno.
•
Evolución de DATEX II a un modelo semántico. Para ello se necesita especificar un nuevo modelo
de datos y de intercambio para un nodo DATEX II que trabaje de forma nativa en un modelo
semántico, y que ofrezca la posibilidad de compatibilidad hacia la versión actual de DATEX II. Para la
consecución de este objetivo se propone seguir los siguientes pasos:
o
Adaptación del modelo de datos de DATEX II a un modelo basado en ontologías: Tomando
como base los trabajos ya realizados al respecto en (Canós Gandía, 2003), se propone
realizar una revisión y actualización de la ontología ya descrita en base a la última versión
publicada de DATEX II.
o
Pasarela DATEX II a DATEX II semántico: Para tener una continua provisión de información
que facilite las pruebas posteriores resultaría conveniente la elaboración de una pasarela
que convierta la información DATEX II en el formato semántico definido en la fase anterior.
Debido a la posible complejidad de esta pasarela, ya que existe una gran cantidad de clases
en DATEX II se consideraría la construcción de un prototipo que traduzca únicamente
algunos tipos DATEX II, sirviendo como ejemplo del sistema completo, y permitiendo el
diseño de experimentos en base a los tipos definidos.
18
1. Justificación
o
•
1.5
Evaluación de métodos de consulta a información semántica: La última fase consistiría en
establecer una comparativa práctica entre la aproximación semántica y la aproximación
clásica, comprobando de esta forma la validez del modelo y determinando si este tipo de
aplicaciones inteligentes basadas en semántica puede ser una alternativa a los sistemas
actuales.
Publicación de la información contenida en la base de conocimiento. Para ello se propone en
primera que la definición de una capa de publicación de información basada en perfiles. La
información asociada a un perfil se describiría de forma semántica y especificaría de forma exacta
los parámetros en base a los cuales pretende el cliente que sea publicada la información del
sistema. Filtrado en base a preferencias geográficas o características de la información, e incluso
formato propio de la información (factor multimodal) serían parámetros interesantes para expresar
en el modelado de un perfil de usuario. Una vez conseguido este objetivo, será posible ampliar de
forma sencilla el sistema para que publique la información en un determinado formato, y sólo
aquella información que responda a ciertas características (prioridad, localización,…) que haya
definido el usuario. Este apartado es, a priori, el que mejor va a permitir explorar los trabajos ya
realizados buscando posibles mejoras, ya que implica tareas potencialmente complejas como
modelización de usuarios o el establecimiento de reglas de filtrado. Se propone probar las
capacidades de esta plataforma especificando para su implantación los siguientes escenarios de
uso:
o
Información semántica: En base a la ontología definida, no se establece ningún tipo de
filtrado ni de conversión, esto es, se obtiene directamente la información contenida en el
sistema.
o
Información georreferenciada: Ofrecería información de forma que fuera fácilmente
representable en un mapa. El formato de salida podría ser cualquier formato estándar
basado en georreferenciación o incluso otros modelos semánticos especificados por
terceros. Para evitar que la salida sea demasiado abundante, este perfil podría llevar
asociados algunos filtros de información (por fecha, prioridad, etc.).
o
Perfil de publicación RDS-TMC: Caso de uso concreto en el que la información semántica
sería transformada a un formato de intercambio compatible con un servidor RDS-TMC.
MATERIALES UTILIZADOS
Para el desarrollo y ejecución de las aplicaciones y gestión de modelos creados a partir del presente
trabajo fue utilizado un ordenador con las siguientes características:
•
Procesador Intel Core 2 Duo T7250 2GHz.
•
Memoria RAM 2 GB.
•
Red: 100 Mbit acceso local, 1 Mbit acceso Internet.
En cuanto a recursos de investigación, además del apoyo del propio grupo, la universidad dispone de
subscripciones a una gran cantidad de revistas que serán utilizadas intensamente. Entre ellas destaca la
librería digital de IEEE, accesible vía Web a través de:
http://ieeexplore.ieee.org
Este portal integra un buen número de revistas tecnológicas, estando muchas de ellas referidas
directamente con el área de las ciencias de la computación, que ocupará fundamentalmente la temática
del presente trabajo.
19
Por otra parte, en un trabajo de las presentes características resulta necesaria la interacción con otros
investigadores que utilicen las mismas herramientas. En concreto, para facilitar la resolución de
dificultados con el software utilizado, se consideró interesante la subscripción a las siguientes listas de
discusión:
•
Jena para desarrolladores: [email protected]
•
Usuarios de Protégé: [email protected]
•
Feedback Protégé 4: [email protected]
•
Protégé OWL: [email protected]
•
Grupo de discusión sobre Protégé: [email protected]
•
Usuarios de Pellet: [email protected]
Por otra parte, se ha considerado adecuada la subscripción a otras listas de distribución de grupos de
trabajo relacionados con la Web Semántica:
•
Web Semántica: [email protected]
•
OWL Working Group: [email protected]
•
RDF Data Access Working Group (SPARQL): [email protected]
•
RDF Working Group: [email protected]
•
RDF Interest Group: [email protected]
1.6
ORGANIZACIÓN DE LA MEMORIA
Los siguientes capítulos detallan el trabajo realizado en base a los objetivos principales que se han
planteado en el apartado anterior. En el siguiente capítulo se aborda la revisión bibliográfica sobre los
temas con los que se trabajará. Tal como se ha definido en el primero de los objetivos planteados, esta
revisión se ha centrado en la búsqueda de información sobre el estado actual de la investigación en lo
que a la Web Semántica se refiere.
Los capítulos 3 y 4 analizan el trabajo realizado en base al segundo y tercero de los objetivos del trabajo.
En el primero de estos capítulos se analiza la aplicación de semántica al modelo DATEX II. Se describe
además, primero desde una perspectiva más teórica hasta llegar a ejemplos de implementación, cómo
se ha llevado a cabo esta evolución del modelo, presentando la ontología desarrollada y algunas
aplicaciones de prueba utilizadas para comprobar su validez. El capítulo 4 define la plataforma de
filtrado que se ha especificado, y que servirá como base de pruebas de los escenarios de uso de prueba
que se han definido en los objetivos.
Posteriormente, en el capítulo 5, se analizan los resultados obtenidos, comentando las implicaciones
que puedan tener y obteniendo unas primeras conclusiones, que serán sintetizadas en el capítulo 6,
planteando además si se han cumplido los objetivos planteados y la información de relevancia que se
desprende de ellos. Por último, en el capítulo 7, se comentan posibles líneas de investigación que
quedarían abiertas después del presente trabajo.
20
2. Estado del arte
2
ESTADO DEL ARTE
El presente trabajo comprende temas muy dispares. En el dominio del tráfico han aparecido avances
muy importantes en los últimos años, sobre todo en el sector de los Sistemas Inteligentes de Transporte
(ITS), que abarca multitud de nuevas tecnologías aplicadas a este dominio. Una de estas tecnologías que
ya se han aplicado es el concepto de la Web Semántica, que representa una instancia del viejo concepto
como es la representación del conocimiento aplicado a entornos Web.
Se ha dividido este apartado en cuatro partes básicas. La primera parte comentará el estado del arte de
la parte más teórica del trabajo, desde la Inteligencia Artificial hasta la Web Semántica. El segundo
apartado analizará el estado actual en cuanto a los Sistemas Inteligentes de Transporte desde un punto
de vista práctico. A modo de conclusión de estos dos primeros apartados, se analizará el material
aparecido relativo a ambos campos, examinando cómo puede aplicarse el plano teórico al plano
práctico, en busca de obtener mejoras en los sistemas que se acaban produciendo.
Por último, se comentan los últimos avances en cuanto a la modelización de usuarios y a sistemas de
recuperación de información semántica, estudios que resultarán fundamentales para llevar a cabo la
creación de la plataforma de publicación de información semántica.
2.1
REPRESENTACIÓN DEL CONOCIMIENTO
Los siguientes apartados intentan ofrecer una idea global del estado actual en todos aquellos campos
relacionados con la representación del conocimiento. Comenzando desde el plano más teórico, y
definiendo los conceptos básicos de forma breve, se irá profundizando cada vez más en las aplicaciones
de cada campo, llegando al objeto de aplicación final del presente trabajo, la Web Semántica y la
infraestructura que la rodea.
2.1.1 CONCEPTOS GENERALES
La representación del conocimiento fue desarrollada primeramente como una rama pura de la
Inteligencia Artificial. Sin embargo, poco a poco esta rama se ha ido desmarcando de la idea original de
esta parte de las ciencias de la computación. En (Sowa, 1999) se define la Inteligencia Artificial como la
“ciencia de diseño de sistemas computacionales que lleven a cabo tareas que normalmente requerirían
de la inteligencia humana”. Tal y como comenta el autor, la realidad demuestra que una gran cantidad
de aplicaciones – muchas de ellas relacionadas con representación del conocimiento – necesitan de la
inteligencia humana para su funcionamiento. Una definición de representación del conocimiento que
tendría en cuenta todos estos matices podría ser la enunciada por el mismo Sowa: “área multidisciplinar
que aplica teorías y técnicas de tres campos: Lógica, Ontologías y Computación”.
Para este autor, las ontologías definen la tipología de cosas que existen en el dominio de la aplicación
(jugadores), la lógica ofrecería una visión formal y reglas de inferencia (reglas de juego) y la computación
lleva a un plano práctico esta representación del conocimiento, distinguiéndolo de la filosofía (partido).
En (Davis, 2001) la representación del conocimiento se describe como el estudio de “cómo las creencias,
intenciones y juicio de valores de un agente inteligente pueden ser expresados en una notación
transparente y simbólica que permita razonamiento automático”. Este razonamiento automático ofrece
ciertas posibilidades a las aplicaciones prácticas que hagan uso de esta rama de la Inteligencia Artificial
que no podrían ser alcanzadas de ninguna forma en los desarrollos actuales.
Existen diferentes puntos de vista para abordar el problema de la representación del conocimiento.
Desde sistemas basados en lógica matemática (lógica de predicados y sistemas basados en reglas) hasta
21
sistemas de representación basados en estructuras de datos (redes semánticas, marcos o frames,
grafos, redes de Petri), todos ellos ofrecen diferentes métodos para la representación del conocimiento.
Este trabajo se ha basado en el uso de ontologías, una metodología moderna y potente de
representación de conceptos del mundo real y que permite razonar sobre ellos. Se ha elegido esta
metodología en contraposición a las otras, debido a que se ajusta exactamente a los objetivos del
proyecto. Por ejemplo, en (Staab, Brewster, & O’Hara, 2004), se comenta que “una gran parte de las
definiciones de ontología insisten en que una ontología específicamente representa estructuras y
conceptos comunes y compartidos”, lo cual se ciñe especialmente al objetivo de establecer un modelo
semántico común para el intercambio de información de tráfico.
2.1.2 ONTOLOGÍAS
Como se ha comentado en el apartado anterior, las ontologías serán utilizadas como base del presente
trabajo. Sin embargo, aunque se ha dado en los últimos tiempos un enfoque distinto al término, las
ontologías es un concepto filosófico muy antiguo en su idea inicial. Una ontología, según la Real
Academia Española de la lengua es la “parte de la metafísica que trata del ser en general y de sus
propiedades trascendentales”, un concepto que ya fue utilizado por Aristóteles. Actualmente se ha
extendido el término para referirse a las definiciones de jerarquías dentro de un dominio, así como sus
relaciones y las reglas que siguen los conceptos especificados.
En (Brewster & Kieron, 2007), se ofrece la siguiente definición simple pero que resume totalmente el
uso actual de las ontologías: “una ontología es un modelo del mundo el cual puede ser usado para
razonar sobre él”.
Aunque en estas definiciones ya han aparecido algunos términos que componen las ontologías
(conceptos, relaciones, reglas), en (Samper Zapater J. J., 2005), tomando como base a (Gruber, 1993) se
detallan los cinco elementos que componen una ontología:
•
Conceptos: sujetos básicos que se intenta formalizar sobre cualquier tipo de clase.
•
Relaciones: enlace entre los conceptos, cómo interactúan los conceptos del dominio.
•
Funciones: tipo de relación en la que el elemento es el resultado de la aplicación directa de una
operación sobre varios conceptos de la ontología.
•
Instancias: objetos particulares de un concepto.
•
Axiomas: teoremas que se declaran sobre relaciones, y que deberán cumplir los elementos de la
ontología. Es la clave de la inferencia de conocimiento.
En un ámbito de uso más aplicado, las ontologías son vistas en la actualidad como herramientas
aplicables a la resolución de problemas en el campo de la Ingeniería del Software. Estos métodos
añaden soporte para Ingeniería del Conocimiento e Inteligencia Artificial y ayudan al modelado de
algunos dominios del mundo mediante un método basado en el etiquetado de conceptos, atributos y
relaciones, que usualmente se distribuyen en jerarquías basadas en especializaciones y generalizaciones
(Simperl & Elena, 2009). Existe una gran variedad de ejemplos de uso de ontologías como apoyo en el
modelado de problemas del mundo real en campos tan dispares como Química (Morbach, Yang, &
Marquardt, 2007), Filosofía (Kim, Choi, Shin, & Kim, 2007) o la propia Ingeniería del Software (Biolchini,
Mian, Natali, Conte, & Travassos, 2007).
22
2. Estado del arte
Figura 1: Ejemplos de jerarquías (Biolchini, Mian, Natali, Conte, & Travassos, 2007)
En este ámbito de aplicación las ontologías estarían compuestas por un vocabulario de términos, así
como una especificación de su significado (generalmente formal), lo cual incluye propiedades y
relaciones entre conceptos. Estos componentes de las ontologías necesitan ser descritos mediante un
lenguaje destinado especialmente a ello. Aunque existe una gran cantidad de lenguajes dedicados al
desarrollo de ontologías (Pulido, Ruiz, Herrera, Cabello, Legrand, & Elliman, 2006), en los últimos
tiempos se ha orientado esta descripción de lenguajes a la Web, integrando tecnologías recientes como
los lenguajes de marcado, lo cual ha llevado al uso de XML como lenguaje de descripción de lenguajes.
En el siguiente apartado se consideran las últimas aproximaciones aparecidas, centradas en el concepto
de la Web Semántica, que han hecho explotar el antiguo concepto de las ontologías potenciando el
surgimiento de nuevas aplicaciones inteligentes. En especial, se analizará el formato de descripción OWL
(Ontology Web Language), cuyo nombre da una idea aproximada de la fusión de ambos conceptos.
2.1.3 WEB SEMÁNTICA
Desde que en 2001 Tim Berners-Lee publicara un artículo (Berners-Lee, Hendler, & Lassila, The Semantic
Web: A new form of Web content that is meaningful to computers will unleash a revolution of new
possibilities, 2001) sobre un nuevo enfoque que debía darse a la Web actual, han surgido multitud de
experiencias y trabajos que le han dado la razón y que ha hecho considerar seriamente a la Web
Semántica como la Web del futuro.
23
1
En contraposición a la Web actual, orientada a que el conocimiento sea intercambiado
entre humanos, la Web Semántica se rige por el principio que deberían ser
principalmente máquinas y no humanos las que recibieran, procesaran e intercambiaran
información en la Web del futuro. Para ello, el lenguaje de la Web en este escenario no
debería estar orientado a la presentación de la información de forma inteligible al ser
humano, sino a permitir incluir de forma sencilla grandes cantidades de metainformación
que identifiquen unívocamente los conceptos que se pretenden transmitir, de tal forma
que puedan ser entendidos por todas las aplicaciones que interactúen con dicha información. Además,
resulta imposible no pensar que quien reciba el mensaje no será sino un sistema experto (agente) que
tendrá la capacidad de razonar sobre dicha información, lo que llevaría al siguiente paso: pensar que
este lenguaje de descripción se encontrará mucho más cercano a la lógica matemática que a la mera
lista de conceptos no relacionados que se distribuye actualmente en la Web.
Para Berners-Lee, la Web Semántica debería constar de cuatro componentes o características
principales:
•
Expresión de significado: debe añadir significado y estructura al contenido de la Web actual.
•
Representación del conocimiento: no debe suponer un impedimento para que se represente el
conocimiento de forma adecuada y se pueda razonar sobre él.
•
Ontologías: adaptación del concepto antiguo de Ontología a la Web. Se encarga de plasmar el
conocimiento del dominio en un formato común entendible por cualquier elemento del sistema.
•
Agentes: actores que deberían intercambiar la información, substituyendo a los humanos, y
encargándose de presentar de forma adecuada la información procesada al usuario.
En los próximos apartados se efectúa una revisión de algunas de las características más importantes de
la Web Semántica, desde su arquitectura hasta las herramientas que permiten llevar al plano práctico
las ideas que la describen.
1
Logotipo de la Web Semántica extraído de (W3C - Semantic Web Working Group, 2009).
24
2. Estado del arte
2.1.3.1 ARQUITECTURA
La Web Semántica se estructura en capas, siguiendo el modelo de la Figura 2.
Figura 2: Estructura en capas de la Web Semántica (W3C - Semantic Web Working Group, 2009)
En la capa inferior aparece el concepto de URI (Universal Resource Identifier) que muestra por sí solo un
gran cambio de concepto en relación a la Web actual. Cada recurso de la Web Semántica es único y se
puede identificar de forma unívoca dentro de la Web simplemente referenciando su URI. En las capas
superiores se disponen tanto los lenguajes para albergar contenidos (XML y sobre todo RDF) como los
metalenguajes que definen las restricciones de los primeros (principalmente OWL). Además se
entremezcla el lenguaje propio de intercambio de información entre nodos de la Web Semántica: el
lenguaje de consulta SPARQL. Todos estos lenguajes mencionados serán comentados en mayor detalle
en el apartado Lenguajes de la Web Semántica.
Las capas superiores están todavía en fase de investigación y definen conceptos más abstractos y que
resultan novedosos si son comparados con la Web actual. El propósito de estas capas es elaborar un
conjunto de reglas (unifying logic) que puedan ser probadas por un agente (proof), para determinar si un
sitio Web semántico es confiable o no (trust).
Por último, no se ha dejado de tener en cuenta la seguridad en todas estas capas, permitiendo la
inclusión de técnicas criptográficas durante todo el proceso.
25
2.1.3.2 METODOLOGÍA DE MODELADO
Existe una gran cantidad de recomendaciones para el desarrollo de ontologías, entre las cuales destaca
una orientada al objetivo de la aplicación conocida como Methontology (Mariano Fernández, 1997). En
(Samper Zapater J. J., 2005) se realiza una completa revisión de las alternativas clásicas más utilizadas.
En los últimos años la investigación en este campo ha avanzado hacia el ámbito de la Ingeniería, con la
aparición de nuevas metodologías que buscan facilitar a las aplicaciones el uso de ontologías (Biolchini,
Mian, Natali, Conte, & Travassos, 2007), (Sarder & Ferreira, 2007). Entre ellas destaca MENTOR
(Sarraipa, Silva, Jardim-Gonçalves, & Monteiro, 2008), que orienta el desarrollo de la ontología a facilitar
que la información sea compartida por un conjunto de organizaciones, así como UPON (Nicola,
Missikoff, & Navigli, 2009), completa metodología que convierte el desarrollo de una ontología en un
proyecto software.
Por último, una visión todavía más práctica se presenta en (GaSevid, Djuric, Devediid, & Damjanovid,
2004). Este enfoque consiste utilizar UML y metodologías actuales como MDA (Model Driven
Architecture) para el desarrollo de ontologías que permitan una fácil integración en las aplicaciones
actuales. Posteriormente esta idea fue ampliada en (Cranefield & Pan, 2007), (Wongthongtham, Dillon,
Dillon, & Chang, 2008) y también en (Manuel Noguera, 2009). En todos estos trabajos se estudian
diferentes aproximaciones para la transformación de un modelo basado en UML a un modelo
ontológico, que posteriormente será enmarcado en arquitecturas reales. Debido a la naturaleza del
proyecto y teniendo en cuenta que DATEX II sigue exactamente esta metodología de desarrollo, este
último enfoque será de gran utilidad y será por tanto tenido en cuenta durante todo el ciclo de vida de
las ontologías y aplicaciones que se desarrollen.
Por otra parte, existe una guía sencilla de desarrollo (Noy & McGuinness, Ontology Development 101: A
Guide to Creating Your First Ontology, 2001), que ya fue utilizada en (Canós Gandía, 2003), por lo que
será tomada también muy en cuenta para establecer los puntos base en la creación de la ontología:
•
Determinar el dominio y alcance de la tecnología: ¿qué se estudia?
•
Considerar la reutilización de ontologías existentes: ¿es posible aprovechar investigaciones previas?
•
Enumeración de los términos más importantes: definición del vocabulario de trabajo.
•
Definición de las clases y su jerarquía: modelado de los objetos del dominio.
•
Definición de las propiedades de las clases: particularización de los objetos del dominio.
•
Detalle de las propiedades a bajo nivel: rango, dominio, cardinalidad.
•
Creación de instancias: definición de elementos finales del dominio, “literales” inmutables.
2.1.3.3 LENGUAJES DE LA WEB SEMÁNTICA
Según se ha analizado en la estructura de la Web Semántica, existen distintos aspectos que resulta
necesario definir desde las aplicaciones que deseen hacer uso de las características de esta tecnología.
Desde la definición de lenguajes hasta la consulta de bases de conocimiento, pasando por el necesario
formato que se encargue de albergar el contenido necesitan ser definidos.
Almacenamiento de contenidos
Al igual que HTML es el lenguaje de la Web actual (aunque también XML es muy utilizado en la
actualidad (Martín & Martín, 2005) para intercambio primitivo de información entre aplicaciones Web),
26
2. Estado del arte
para la Web Semántica el formato por antonomasia es el Resource Description
Framework o RDF2 (W3C - RDF Working Group, 2009). Este lenguaje, que a su vez es
un vocabulario XML, escapa del objeto básico de HTML (presentación de información),
y es visto realmente como un lenguaje de intercambio e incluso almacenamiento e
integración de recursos de la Web Semántica.
RDF presenta la información en forma de tripletas, ternas de tres componentes:
•
Sujeto: recurso que se va a definir.
•
Objeto: otro recurso, que define al sujeto a través de una propiedad.
•
Predicado: establece la relación que existe entre sujeto y objeto.
Sin embargo, RDF ha sido creado únicamente para la creación y almacenaje de recursos, pero no para
definir relaciones y restricciones entre conceptos ni para definir el vocabulario del dominio. De esta
forma, resulta necesario un segundo lenguaje que se encargue de ello. En el siguiente apartado se
comentan las alternativas más actuales para la definición de vocabularios y relaciones.
Lenguajes de definición de ontologías
Existen multitud de lenguajes destinados a este fin (Pulido, Ruiz, Herrera, Cabello, Legrand, & Elliman,
2006), destacando entre ellos RDF Schema o RDF(S), lenguaje utilizado de forma activa hasta la
aparición de OWL (Ontology Web Language). Este último, que nació como una extensión a RDF Schema,
se ha convertido en estándar de facto en los últimos años para la definición de ontologías para la Web
Semántica y es sin duda el más utilizado en los trabajos actuales. Por ejemplo en (Ko, Kim, Kim, Lee, &
Lim, 2005) se describe un sistema para describir noticias de un periódico, y en (Noy & Rubin, 2008) se
adapta un sistema clásico de clasificación anatómica a un modelo semántico utilizando dicho lenguaje.
La extensión en el uso de las ontologías por la comunidad científica ha hecho que se acaben organizando
en repositorios, en los cuales los usuarios pueden comprobar si se ha modelado alguna parte del
problema con el que están trabajando y por tanto reutilizar el trabajo ya realizado. Algunos de estos
repositorios son de tipo genérico (protégé team, 2009) y otros muchos de tipo específico, entre los que
destacan un repositorio para modelos sobre genética (Gene Ontology Consortium, 2009) y otro para
aplicaciones relacionadas con biomedicina (The Open Biomedical Ontologies, 2009).
OWL fue diseñado sobre una capa sólida de lógica (zhihong & mingtian, 2003), lo cual permite que los
motores de inferencia puedan efectuar razonamiento de forma sencilla. El grupo de trabajo de OWL se
marcó como objetivo (W3C - OWL Working Group, 2004) que el diseño de OWL facilitara a los usuarios
los siguientes aspectos:
•
Compartición: Las ontologías deberían poder ser accedidas públicamente como una base de
conocimiento mundial. Además, las ontologías deberían poder ser extendidas de forma sencilla
para incorporar nuevos conceptos aplicados a un dominio.
•
Evolución: Debido a los previsibles cambios y adaptaciones continuas, la gestión del ciclo de vida de
las ontologías (control de versiones) no debería suponer un problema.
•
Interoperabilidad: Es posible que diferentes ontologías modelen el mismo concepto. Esto no
debería ser visto como una duplicidad de conceptos, y las ontologías deberían permitir que ambas
definiciones sean complementadas la una a la otra.
2
Logotipo de RDF extraído de (W3C - RDF Working Group, 2009)
27
•
Detección de inconsistencias: En el caso de que dos ontologías diferentes definan conceptos
inconsistentes la una con la otra, deberá existir un proceso definido que permita su detección para
determinar donde se encuentra el fallo.
•
Expresividad vs escalabilidad: Es necesario encontrar un balance entre ambos conceptos. Un
lenguaje muy expresivo se torna excesivamente completo, y un lenguaje muy escalable será tan
general que podría perder su expresividad.
•
Facilidad de uso: Curva de aprendizaje pequeña. Los conceptos deberían ser independientes de la
sintaxis.
•
Compatibilidad con otros estándares: Principalmente con los estándares habituales de la Web
(XML, XML Schema, RDF) y otros estándares fundamentalmente de modelado (UML).
•
Internacionalización: Una unidad de conocimiento podrá ser expresada de forma muy distinta
según el idioma en lenguaje natural que se esté utilizando. Todas estas unidades de conocimiento
deberían ser compatibles, pero sin descuidar la idea de que finalmente esta información será
presentada al usuario y por lo tanto, deberían poder ser expresables en el lenguaje propio de cada
usuario.
Una característica importante de OWL es la conocida como Open World Assumption, una idea heredada
de la lógica matemática que denota que no se puede afirmar que algo no existe si no se ha escrito un
enunciado específico para ello. En un entorno clásico (por ejemplo, una base de datos), si después de
realizar una búsqueda no se encuentra un determinado resultado se puede tomar como no existente.
En el caso de la Open World Assumption, el resultado en este caso sería indicar que no hay datos
suficientes para decidir una respuesta. Esta característica debe ser tenida en cuenta en los razonadores
de inferencia que se encargan de realizar deducciones a través de los axiomas de la ontología. En el
desarrollo de la ontología se debe tener especial cuidado disponiendo axiomas de clausura para
asegurar que lo descrito responde a los requisitos planteados.
Por otra parte, otra característica que influye indirectamente en los razonadores es el conjunto de
propiedades lógicas de OWL que se estén utilizando, también conocido como expresividad. Aunque
OWL es muy extenso, el uso o no de determinadas posibilidades puede cambiar la complejidad temporal
e incluso la decidibilidad de las acciones de inferencia de estos razonadores. En función de esta
característica, se definieron tres categorías conocidas como especies en la primera especificación de
OWL (W3C - OWL Working Group, 2004):
•
OWL Full: Aunque ofrece una expresividad completa, no garantiza la decidibilidad, y no es nada
eficiente, por lo que su uso sólo se recomienda en casos particulares.
•
OWL DL: Basado en descripción lógica (Description Logic), es decidible (se puede computar en un
tiempo finito), permite la construcción de razonadores.
•
OWL Lite: Sencillo de implementar, conceptualmente simple, pero con un ámbito de uso muy
pequeño debido a su baja expresividad.
En la versión 2 de OWL (W3C - OWL Working Group, 2009), además de otras mejoras, la nomenclatura
de especies ha sido cambiada al concepto de perfil. Esta nomenclatura, además de mantener las tres
especies anteriores, se orienta además la existencia de nuevos perfiles que presenten características
particulares interesantes para ciertos tipos de aplicaciones:
•
OWL 2 Full: Evolución de OWL Full, incluye toda la funcionalidad de OWL 2. Sin embargo, puede
convertir el lenguaje en indecidible, lo cual hace que la construcción de razonadores sea una tarea
complicada, y además no resulta práctico para muchas aplicaciones.
28
2. Estado del arte
•
OWL 2 DL: Versión restringida de OWL 2 Full. En este caso sí existen razonadores que cubren toda la
expresividad del lenguaje.
•
OWL 2 EL: Perfil cercano a la descripción lógica EL++, que según (W3C - OWL Working Group, 2008)
asegura un tiempo polinomial para la resolución de problemas de razonamiento. Es sencillo de
implementar y permite una gran escalabilidad para expresiones complejas, aunque la expresividad
que proporciona es bastante limitada. Por ejemplo, no permite el uso de cuantificadores
universales.
•
OWL 2 QL: Variante de OWL-Lite, muy habitual en tareas de integración en bases de datos. Resulta
muy sencillo extender los habituales lenguajes relacionales (SQL), incorporando consultas con los
axiomas definidos por el subconjunto. Finalmente, facilita el mapeado entre UML y Diagramas
Entidad Relación, con lo que la representación de esquemas de datos es bastante inmediata. En
cuanto a expresividad sigue siendo bastante limitada, por ejemplo no permite cuantificadores
existenciales ni propiedades encadenadas.
•
OWL 2 RL: Indicado para aplicaciones que requieren un razonamiento escalable sin sacrificar
demasiada expresividad. Está orientado fundamentalmente a ser utilizado en otras tecnologías
basadas en reglas, facilitando el razonamiento. En OWL 2 RL no pueden expresarse reglas que digan
que la existencia de una instancia lleva a la existencia de otra instancia, por ejemplo “cada persona
tiene un padre”.
Figura 3: Diagrama de Venn de los perfiles de OWL 2 (W3C - OWL Working Group, 2009)
El perfil DL es, en base a sus características, el perfil de trabajo más utilizado, y en el que se basará el
presente trabajo, ya que aporta una gran expresividad sin sacrificar excesivo rendimiento. Dentro de
este apartado es necesario mencionar que a este sublenguaje es posible aplicar los conocimientos ya
existentes en cuanto a descripciones lógicas se refiere. Por ejemplo, de ahora en adelante se utilizará la
notación de la Figura 4, resumen extraído de (Wikipedia, 2009) contrastado en la fuente inicial (Baader,
Calvanese, Nardi, & Patel-Schneider, 2003).
29
Figura 4: Convención en la notación de expresividad DL (Wikipedia, 2009)
Esta notación ha sido adoptada por convenio para denotar la expresividad DL que tendrá la ontología
definida e incluso existe una aplicación Web de la Universidad de Manchester (Zolin, 2007) que ofrece
valiosa información sobre la complejidad espacial y temporal para las distintas combinaciones de
propiedades que se especifiquen.
A continuación se enumeran los conjuntos de propiedades más comunes, aunque existen multitud de
combinaciones en función de la expresividad que se desee utilizar:
•
: Unión, intersección y negación sobre conceptos y relaciones.
•
:
•
+ propiedades funcionales, transitivas y jerarquía de propiedades.
+ relaciones inversas entre propiedades y cardinalidad.
:
•
:
•
: OWL-Lite.
•
: OWL-DL.
•
: OWL 2.
+ tipos de datos y clases enumeradas.
En (Zolin, 2007) existen además enlaces a artículos y trabajos que se han esforzado en determinar las
propiedades de muchos de los tipos distintos de expresividad. En el presente trabajo únicamente se
determinará la expresividad en los resultados como determinación de una característica más de las
ontologías definidas, así como algunas de las propiedades que se puedan deducir automáticamente en
base a los trabajos ya realizados. Se dejará como trabajo futuro, por lo tanto, el análisis minucioso de las
propiedades lógicas de las ontologías desarrolladas en el trabajo.
Un último aspecto que merece la pena destacar son los intentos por la ampliación de algunas
características de OWL para adaptarse a ciertos dominios específicos. En (Ding & Peng, 2004) se
propone una extensión de OWL para soportar de forma nativa modelos estadísticos basados en
probabilidad. Otra ampliación en la que se ha trabajado ha sido la aplicación de lógica difusa a OWL,
para soportar imprecisión en el razonamiento, con lo que se facilita la representación del conocimiento
para algunos términos exclusivamente manejados por humanos. En el Anexo II se realiza una revisión de
la teoría básica sobre lógica difusa y de cómo puede extenderse OWL para soportar este tipo de
definiciones imprecisas.
30
2. Estado del arte
Lenguajes de consulta RDF
Por último, después de analizar el lenguaje de especificación y de intercambio, es preciso realizar una
parada en los lenguajes de consulta a información RDF, ya que servirán como base para la extracción de
información en base a los requerimientos planteados.
Aunque existe una gran cantidad de lenguajes de consulta, SPARQL (acrónimo de SPARQL Protocol and
RDF Query Language) se ha ido imponiendo poco a poco hasta llegar alcanzar la categoría de
recomendación de la Web Semántica (W3C - SPARQL Working Group, 2008). En el presente trabajo se
únicamente se considerará SPARQL debido a esta condición de estándar de facto de la Web Semántica.
Además, fue el lenguaje utilizado en (Canós Gandía, 2003), lo cual permitirá la reutilización de algunos
resultados obtenidos en este trabajo y facilitará una posible comparación de estos resultados.
En las especificaciones del lenguaje, además del propio lenguaje de consulta, se especifica también un
protocolo intercambio basado en WSDL 2.0 (W3C - SPARQL Working Group, 2008), así como un
vocabulario XML para describir los resultados obtenidos de la consulta (W3C - SPARQL Working Group,
2008).
Una ventaja importante de este lenguaje de consulta es el soporte nativo de integración de distintas
fuentes. SPARQL trata todo el “grid” de la Web Semántica como espacio de consulta, permitiendo así la
obtención de recursos de distintas fuentes RDF. Por ejemplo, en (Canós Gandía, 2003) se probó una
consulta SPARQL que obtenía los elementos sindicados de los blogs dispuestos en lugares diferentes del
hiperespacio de tres gurús de la Web Semántica (Danny Ayers, Ivan Herman y Tim Berners Lee).
Siguiendo con esta idea de integrar distintas fuentes en (Langegger, Blöchl, & Wöß, 2007) se propone
una arquitectura que combina eficientemente distintas fuentes RDF dispuestas en la Web.
En el caso de acceso a información semántica mediante lenguajes de programación, la comunidad ha
creado una API de acceso a datos RDF (RDF API), que ha sido implementada por muchas librerías de
interacción con la Web Semántica en diferentes lenguajes. Esta API ofrece métodos para consulta
basados en la recuperación de tripletas RDF. Así mismo Ontology API, más novedoso, utiliza
directamente conceptos de ontologías (Individual, Class, etc.) para el acceso a datos, brindando al
programador una capa de más alto nivel a costa de un pequeño overhead en los recursos necesarios
para su uso.
Conclusiones
La arquitectura de la Web Semántica requiere del uso de lenguajes para especificar de forma clara todos
los elementos con los que va a interactuar una aplicación. Tal y como se definía HTML o XML en la Web
actual como lenguaje para albergar contenido, para la Web Semántica este lenguaje será el RDF, en el
cual se definen los recursos y propiedades sobre ellos.
XML Schema está sirviendo en los últimos años para la definición de nuevos vocabularios XML que se
ajusten a las aplicaciones actuales. En la Web Semántica es necesario asimismo un lenguaje de
definición de ontologías, que restrinja de alguna manera los vocabularios y propiedades que se pueden
utilizar en un determinado dominio. Aunque existen diferentes lenguajes, OWL se ha convertido sin
duda en el estándar de facto de la Web Semántica.
Por último, otra característica básica para aplicaciones que trabajen con la Web Semántica es un
lenguaje de consulta para la extracción de información. En aplicaciones clásicas el lenguaje SQL ha sido
ampliamente utilizado para extraer información de base de datos, mientras que en los últimos años y
bajo ciertas condiciones, los lenguajes XQuery y XPath han servido para atacar almacenes de datos XML.
31
La Web Semántica ha elegido SPARQL como lenguaje de consulta de la Web, teniendo en cuenta
además las APIs de tipo programático, que pueden resultar muy útiles en determinadas situaciones.
2.1.3.4 SERVICIOS WEB SEMÁNTICOS
Una pieza clave para la Web Semántica son los Servicios Web Semánticos (SWS), que ofrecen el
dinamismo necesario a la Web para la interacción de aplicaciones. En (Hepp, 2006) se destaca que, en
ámbitos empresariales, los proveedores centran sus modelos de negocio en ofrecer servicios en lugar de
datos en sí, por lo que se hace necesaria la existencia de estos servicios avanzados.
Mediante una comparación simple, sería posible contrastar la Web en sus inicios, ofreciendo
información estática (HTML), a la Web actual, donde existen complejas aplicaciones Web que acceden a
bases de datos para obtener la información que es presentada al usuario está al orden del día.
Figura 5: Comparativa entre los servicios Web actuales y los SWS. Adaptada desde (Fensel & Bussler, 2002)
Servicios Web clásicos
En (W3C Working Group, 2004) se define un servicio Web como “un sistema software diseñado para
soportar interacción máquina-máquina de forma interoperable en una red. Tiene una interfaz descrita
en un formato procesable por una máquina (en concreto WSDL). Otros sistemas interaccionan con el
servicio Web de la forma especificada en su descripción mediante mensajes SOAP, típicamente
mediante el uso de HTTP y serialización XML junto a otros estándares de la Web”.
Esta definición ya tiene en cuenta muchos de los conceptos propios de la Web Semántica, por ejemplo
el escenario de interacción se describe como máquina-máquina y no sigue el paradigma hombremáquina habitual. En la Figura 6 se especifica el esquema general de conexión a un servicio Web, en el
cual aparecen los elementos de sistemas basados en servicios Web.
32
2. Estado del arte
Figura 6: Proceso general de conexión a un servicio Web (W3C Working Group, 2004)
El primer concepto en el que aparece la semántica es en la propia descripción de los servicios. Un WSD
(Web Service Description) no es más que una descripción de tipo semántico sobre los servicios que
ofrece un proveedor, especificando las operaciones que ofrece detallando todos los parámetros
necesarios para la conexión al servicio, por ejemplo los parámetros de entrada y salida que acepta. Para
la descripción de todas estas características técnicas se utiliza el lenguaje WSDL (Web Service
Description Language).
Otro concepto semántico, que adquirirá especial relevancia para la Web Semántica es la definición de
un agente. El agente es, según (W3C Working Group, 2004), la pieza de software o hardware que envía y
recibe mensajes a un servicio.
Los servicios Web han sido utilizados ampliamente en una gran cantidad de campos de la Ingeniería del
Software gracias a su flexibilidad. Esta flexibilidad hace que, sin embargo, sea necesario restringir
algunas de sus especificaciones para la correcta evolución a los SWS. Además, resulta necesaria una
especificación semántica de los servicios para disminuir la heterogeneidad existente y facilitar así tareas
como el descubrimiento de servicios, muy limitado en la actualidad por la ausencia de herramientas
para determinar que dos servicios que hacen lo mismo en efecto hacen lo mismo. La Web Semántica ya
ofrece estas herramientas (emparejamiento semántico), por lo que resulta apropiada esta evolución
para la mejora de los servicios Web.
Semántica en Servicios Web
Mientras que la interoperabilidad era el objetivo principal en los servicios Web, para los SWS se persigue
la automatización de las operaciones (Martin, y otros, 2007).
Aunque ya existían ideas de evolucionar los servicios Web actuales, los SWS fueron enunciados como
tales en (McIlraith, Son, & Zeng, 2001), donde ya se introducía la presencia de agentes inteligentes en
este tipo de sistemas, así como de lenguajes semánticos para la descripción de servicios.
El primer paso necesario para adaptar los servicios Web a la Web Semántica es el uso de razonadores
lógicos en lugar de lenguajes puramente procedurales para el acceso a los datos intercambiados, cuyo
33
formato cambiará desde las serializaciones XML ad hoc actuales, hasta la generación de tripletas RDF en
base a ontologías conocidas.
Además, para las nuevas arquitecturas basadas en la Web Semántica, es necesario que, algunas
características de los servicios Web clásicos sean mejoras y ampliadas. En (Bachlechner, 2008) se
comenta que el objetivo principal de los SWS, es la automatización del núcleo de la Web. Se intenta que
tareas como el descubrimiento, selección, composición y ejecución entre sistemas, puedan ser llevadas
a cabo con un mínimo de intervención humana. Lo que desde fuera podría ser visto como un complejo
servicio, realmente estaría ejecutando e integrando información de otros servicios de forma
transparente al usuario.
Por lo tanto, es necesario el establecimiento de nuevos lenguajes de definición, más potentes que
WSDL, y que permitan la interacción con otras características de la Web Semántica.
Lenguajes de definición
Aunque existen distintas aproximaciones para la definición de SWS, desde anotar semánticamente
WSDL (WSDL-S) hasta el establecimiento de nuevos lenguajes (Semantic Web Services Language ó
SWSL), actualmente parece que OWL-S (evolución de DAML-S) se está imponiendo poco a poco en la
descripción de SWS.
OWL-S (OWL-S Coalition, 2008) es un conjunto de ontologías basadas en OWL que definen todos los
detalles semánticos de un servicio (Figura 7), definiendo las características funcionales del servicio
(Figura 8) y los procesos involucrados en la invocación del servicio (Figura 9).
Figura 7: Definición semántica del servicio (OWL-S Coalition, 2008)
34
2. Estado del arte
Figura 8: Descripción semántica de los perfiles de acceso a un servicio (OWL-S Coalition, 2008)
Figura 9: Descripción semántica de los procesos asociados a la invocación de un servicio (OWL-S Coalition, 2008)
Arquitecturas basadas en Servicios Web Semánticos
Aunque ya se habían intentado adaptar infraestructuras basadas en agentes a los servicios Web
comunes (Greenwood & Calisti, 2004), para la Web Semántica este tipo de arquitectura se ha utilizado
ampliamente, tornándose el desarrollo de este tipo de infraestructuras uno de los campos más activos
en el dominio de la Web Semántica aplicada.
35
Todos los trabajos que se han basado en estas arquitecturas coinciden en la presencia de plataformas de
agentes inteligentes, compuestas por los siguientes elementos principales (Bachlechner, 2008):
•
Cliente: Entidad que realiza la llamada a un servicio.
•
Proveedor: Entidad que ofrece un servicio.
•
Componente de registro: Ofrece mecanismos de publicación y localización de servicios en un
registro semántico, además de funcionalidades para crear y editar las descripciones de los servicios.
•
Razonador: Utilizado para ofrecer soporte de razonamiento para la interpretación de las
descripciones semánticas y las consultas a las bases de conocimiento.
•
Emparejador: Mediador entre el cliente y el componente de registro durante el proceso de
descubrimiento del servicio y selección.
•
Componente de descomposición: Para servicios compuestos, se encarga de descomponer el
problema y volver a componerlo una vez obtenidas las respuestas de cada servicio invocado.
•
Componente de invocación: Mediador para cualquier invocación de un servicio realizada a un
proveedor, ya sea hecha por el cliente directamente, o por el componente de descomposición.
Uno de los trabajos más destacables en este campo fue (Tomás López, 2006), en el que se construyó una
arquitectura de este tipo para la integración de múltiples servicios, profundizando en tácticas para la
negociación entre agentes. Partiendo de un escenario basado en servicios que ofrecían información
incompleta, se trabajaba para la integración de esta información.
Por su parte, en (Samper Zapater J. J., 2005) también se diseñó una arquitectura de este tipo para
proveer servicios de tráfico, utilizando entre otras la técnica de composición de servicios, con objeto de
ofrecer funcionalidad multilenguaje en uno de los SWS que fueron desarrollados.
Entre las últimas contribuciones destaca una aproximación que facilita la visión entre distintos SWS
(Neiat, Mohsenzadeh, Shavalady, & Rahmani, 2009). Para ello, se construye un framework a partir de
servicios de directorio e intercambio de mensajes SOAP.
Por último, otro artículo aparecido (Hahn, Nesbigall, Warwas, Zinnikus, Fischer, & Klusch, 2008) pone de
manifiesto la falta de modelos generales y utiliza los modelos MDA para centrarse en el establecimiento
de capas (PIM) que engloben los modelos dependientes (PSM), tanto las plataformas de agentes
(especificadas por lo tanto mediante cualquier framework) como las descripciones de servicios
(permitiendo así el uso de diferentes lenguajes de descripción). Estas capas generales pueden permitir,
por ejemplo, la integración entre diferentes modelos semánticos, facilitando la interacción entre los
mismos sin importar los lenguajes y herramientas utilizados para su especificación.
2.1.3.5 HERRAMIENTAS DE LA WEB SEMÁNTICA
Existe una gran cantidad de herramientas asociadas a la Web Semántica, fundamentalmente destinadas
a la definición de ontologías y su posterior validación. Por otra parte, también es posible encontrar
conjuntos de librerías para los lenguajes de programación habituales, que acercan la sintaxis de la Web
Semántica a los lenguajes procedurales habituales.
En el presente apartado se comentan estas herramientas, determinado aquéllas que serán elegidas para
el desarrollo del trabajo a realizar:
•
Editor de ontologías: Permite la edición sencilla de ontologías, generalmente de forma visual y
parecida a los entornos de modelado UML. Algunos de ellos tienen características adicionales como
36
2. Estado del arte
la integración de razonadores o incorporación de formularios para realizar consultas semánticas
desde la propia aplicación. Aunque existen otros editores, el más utilizado es Protégé, que en Junio
de 2009 liberó la versión 4 (protégé team, 2009) , y que será el utilizado en el presente trabajo. Un
aspecto destacable de esta versión es que soporta OWL 2.
Figura 10: Captura de pantalla de Protégé 4 con la ontología Pizza (protégé team, 2009)
•
Razonadores: Ofrecen numerosas herramientas para comprobar que una ontología se ha descrito
de forma adecuada. Validación, comprobación de conceptos no alcanzables, o clasificación son
características habituales en los razonadores. Un detalle importante que se ha comentado ya con
anterioridad es que requieren que la ontología responda al perfil OWL-DL para asegurar su correcto
funcionamiento. De los existentes, Pellet (clark & parsia, 2009) y FaCT++ (Tsarkov & Horrocks, 2009)
son los más habituales y serán utilizados para la validación de las ontologías que se desarrollen.
•
Librerías de utilidades: actualmente Jena (Jena team, 2009) es el conjunto de librerías que ofrece
mayor funcionalidad para el uso de las características de la Web Semántica en los lenguajes de
programación. La versión actual es la 2.6, está escrita en Java y ofrece soporte nativo para OWL y
RDF, además de permitir la interacción con razonadores 3 . Dispone además de una utilidad
interesante llamada schemagen (Jena team, 2008). Esta utilidad, que se ejecuta como una
aplicación dentro de la librería Jena, permite la generación de clases de utilidades Java en la que se
describen todos los recursos definidos en una ontología. Esto simplifica el manejo de recursos y
clases de la ontología, ya que no es necesario escribir cada vez toda la URI del recurso o propiedad,
sino que puede utilizarse directamente un atributo de la clase de utilidades como representante de
esta URI.
3
En especial Pellet, ya que dispone de un conjunto de librerías para ofrecer soporte nativo en Jena 2.
37
•
Gestión de SWS: En (Samper Zapater J. J., Tomás, Carrillo, & Nascimento, 2008) se presenta una
herramienta de visualización de ontologías diseñada específicamente para poder describir las
características de los SWS, lo cual puede resultar de gran utilidad para infraestructuras basadas en
este tipo de servicios.
2.1.3.6 DIRECCIONES FUTURAS
Aunque muchos de los esfuerzos actuales están orientados a la definición de las características de la
futura Web Semántica, existe un grupo de investigadores que piensa que es posible llevar a cabo desde
este momento una migración paulatina desde la Web actual hasta la Web Semántica.
En este sentido y debido a la imposibilidad de llevar a la práctica actualmente algunos de los conceptos
que implica la Web Semántica, están surgiendo nuevos enfoques que extienden ciertas ideas de la Web
actual con ideas que ya han sido descritas para la Web Semántica. Por ejemplo, en (Ankolekar, Krötzsch,
Tran, & Vrandecic, 2008) se compara el pragmatismo total de la Web 2.0, metodología en la que se
basan muchas de las aplicaciones Web actuales, con las teorías de la Web Semántica. Finalmente, el
autor llega a la conclusión de que la Web 2.0 es un intento actual de la Web del futuro, donde se
vislumbran ya conceptos como la ubicuidad de la información o la colaboración entre usuarios.
Otros autores apuntan a que es necesario extender la Web Semántica para aproximarse más a la
realidad para conseguir que sea más fácil llevarlo a la práctica. En (Yu & Wang, 2007) se propone una
extensión de OWL mediante lógica difusa para conseguir modelados más cercanos al mundo.
En cualquier caso, muchos de los autores (Alani, Hall, O’Hara, Shadbolt, Szomszor, & Chandler, 2008),
(Umar & Zordan, 2009) coinciden en que de la Web Semántica actual ya es posible extraer las ideas
necesarias para comenzar a trabajar, e incluso algunos aventuran (d’Aquin, y otros, 2008) que una
nueva generación de aplicaciones basadas en la Web Semántica acabará substituyendo las aplicaciones
actuales.
Por último y a modo de conclusión, parece claro que desde las primeras páginas Web estáticas creadas,
la Web ha incrementado en gran medida su potencial de distribución de información. Nada se opone,
por tanto, a que en un futuro la información intercambiada en la red sean enunciados lógicos provistos
por servicios Web Semánticos en lugar de HTML provisto por servidores Web. La idea de que un agente
sea capaz de recuperar e integrar información de diferentes lugares y presentarla al usuario en base a
sus preferencias personales (formato, modo de presentación, filtrado automático) presenta un posible
escenario futuro plagado de posibilidades.
2.2
SISTEMAS INTELIGENTES DE TRANSPORTE
Los Sistemas Inteligentes de Transporte (de ahora en adelante ITS) se ocupan de la integración de
información y tecnología de comunicaciones con infraestructuras de transporte, vehículos y usuarios.
(ERTICO - ITS Europe, 2007). Estos sistemas están orientados a mejorar la movilidad de personas y
mercancías en las redes viarias a través del uso de las nuevas tecnologías como localización por satélite,
telefonía móvil o redes sin hilos (The Parliamentary Office of Science and Technology, 2009).
Los dos objetivos primordiales de los ITS son la mejora en la seguridad en la carretera y la reducción de
la congestión de las infraestructuras disponibles. Otro componente de gran importancia es la
integración entre sistemas, que adquirirá especial relevancia en el desarrollo del presente trabajo.
En el desarrollo de este apartado se realizará en primer lugar una visión general de algunos servicios
existentes en ITS, centrándose en la experiencia española. La segunda parte de este apartado se
38
2. Estado del arte
centrará en DATEX, modelo de datos que permite el intercambio de información de tráfico entre
administraciones.
2.2.1 SERVICIOS EN ITS
El estudio de los servicios disponibles en España podrá ser fundamental para el presente trabajo por dos
motivos:
•
Posible reutilización de metodologías, arquitecturas e incluso implementaciones de servicios ya
existentes.
•
Interoperabilidad del sistema que se desea desarrollar con algunos de estos servicios, con lo que se
conseguirá que las aplicaciones desarrolladas extiendan su ámbito de uso.
Servicios de información orientados al viajero
Estos servicios permiten a los usuarios elegir el modo y ruta más eficiente a su destino final. Estos
servicios utilizan los ITS para recibir información actualizada y detallada sobre incidentes de tráfico, el
tiempo, obras y eventos especiales. De esta forma es posible estimar de mejor manera el tiempo de
viaje, permitiendo a los conductores tomar las mejores elecciones de ruta y hora de viaje y reducir por
lo tanto la congestión (U.S. Department of Transportation, 2007).
Los siguientes apartados se centrarán en los servicios de información más actuales, centrándose en la
experiencia española, y estudiando como el sistema que se pretende realizar podría hacer uso de estos
recursos para extender su funcionamiento (factor multimodal).
Internet
Una gran cantidad de servicios pre-viaje se focalizan en Internet. Existen portales Web que permiten la
visualización de información de tráfico y gestión de rutas antes de llevar a cabo el viaje, ayudando a la
planificación del mismo.
Habitualmente se utiliza un Sistema de Información Geográfica o GIS para la representación
georreferenciada de los eventos ocurridos, obteniendo una información visual que permita la
interacción con el usuario. En España existen varios portales de este tipo, entre las cuales destaca el
portal etraffic (DGT, 2009).
39
Figura 11: Aplicación etraffic, disponible en http://www.dgt.es (DGT, 2009)
En el presente proyecto sería interesante la representación de esta información generada mediante un
GIS, para permitir una fácil visualización de la información contenida en la plataforma semántica
desarrollada.
RDS-TMC
Servicio en viaje que permite la recepción de información de tráfico en tiempo real en el transcurso del
viaje, permitiendo variar las rutas originalmente planteadas para evitar un incidente de tráfico,
mejorando la experiencia del usuario de la vía y reduciendo la congestión. Funciona mediante la
recepción vía radio de mensajes especialmente preparados para el transporte de información de tráfico
codificada en base al conjunto de estándares ISO 14819 (ISO, 2003). Estos mensajes son decodificados
por un navegador GPS, que informa al usuario del incidente, ya sea de forma activa con un aviso por voz,
o de forma pasiva dibujando en el mapa el incidente o incluso recalculando automáticamente la ruta a
seguir.
40
2. Estado del arte
Figura 12: Arquitectura de un servicio RDS-TMC (Torres Garrigós, 2007)
Desde finales de los años 90 DGT dispone de un servicio RDS-TMC que ofrece cobertura nacional a
través de Radio 3 (Radio Nacional de España S.A., 2005).
Figura 13: Ejemplo de navegador GPS con soporte RDS-TMC (Via Michelin, 2006)
En (Torres Garrigós, 2007) fue desarrollado un servidor de información RDS-TMC, que podría servir
como base para la creación de una extensión más del proyecto a desarrollar, permitiendo la inclusión de
un servicio RDS-TMC en la plataforma semántica como un servicio adicional.
2.2.2 ESTÁNDARES DATEX
DATEX (DATa EXchange) es un estándar de intercambio de información de tráfico
entre sistemas heterogéneos. Esta información de tráfico incluye cualquier situación de
tráfico que afecte o pueda afectar al viajero, desde un accidente que provoca una
retención, al cierre de una estación de servicio en una autopista. A diferencia de los
41
servicios comentados en el apartado anterior, el usuario final no es el viajero, el propósito de DATEX es
facilitar el correcto intercambio entre administraciones y otras entidades estableciendo modelos
comunes que permitan representar la información de cualquier sistema de información de tráfico.
Figura 14: Intercambio vía DATEX entre sistemas heterogéneos de información de tráfico
DATEX I surgió en 1996 como resultado de los esfuerzos de la Comisión Europea (EC) en el dominio de
los ITS. Desde entonces, este estándar – que en su origen sólo especificaba un modelo de datos – se ha
venido utilizando ampliamente en Europa (por ejemplo, hasta la fecha España dispone de 3 nodos
DATEX), y actualmente aún se sigue utilizando en espera de la estandarización de la segunda versión de
dicho modelo. En 2003 fue comenzada la elaboración de las especificaciones técnicas de DATEX II
(García Calderaro, Vidal Peña, Pérez Losa, López López, & Torres Garrigós, 2007), y actualmente se
encuentra en fase de estandarización. Se espera que, además de los países integrantes de la actual red
DATEX I, se sumen otros muchos, abarcando Europa casi en su totalidad.
Por ejemplo, en España, el escenario futuro de conexión de nodos DATEX si se tienen en cuenta sólo
administraciones 4 podría ser parecido al de la Figura 15, en la cual puede observarse la gran
implantación esperada en el ámbito nacional e internacional.
4
Algunas entidades privadas ya han mostrado interés en sumarse a la red de nodos DATEX debido a las facilidades
de intercambio y publicación de información que ofrece el estándar.
42
2. Estado del arte
Figura 15: Escenario futuro de interconexión de nodos DATEX II en España
DATEX II aporta cuatro ventajas principales respecto a DATEX I:
•
Se amplía significativamente el modelo de datos de tráfico. DATEX II ha sido elaborado
minuciosamente atendiendo a las necesidades de cada país, por lo que el modelo resultante resulta
muy completo.
•
El modelo de datos se ha realizado de forma que facilita la extensión del mismo para adecuarlo a
nuevas necesidades que puedan aparecer, tanto del modelo de datos de tráfico como de nuevos
modelos de datos no directamente relacionados con el tráfico, pero que puedan aportar
información valiosa: datos de tráfico, paneles de mensaje variable, cámaras, etc.
•
Se añade un modelo de intercambio basado en servicios Web, lo cual facilita la interoperabilidad
entre distintos nodos. En DATEX I resultaba necesario acordar un protocolo de intercambio para
cada par de nodos que deseaban intercambiar información.
•
Orientado, además de al intercambio, a la publicación de información, lo cual permite que sectores
de información de tráfico y viaje puedan participar en el escenario de difusión de información
mediante este formato común.
La primera de las anteriores ventajas ofrece una razón de peso para la elección de DATEX II como base
del presente trabajo. Como ya se ha comprobado en otros dominios (Wikipedia como enciclopedia o el
movimiento del software libre), los proyectos realizados por una comunidad heterogénea suelen
alcanzar una calidad considerable. Aunque DATEX II no ha sido elaborado por una comunidad abierta
debido a las dificultades técnicas que ello conllevaría, sí ha sido elaborado por un comité de expertos de
distintos países, lo cual permite deducir que DATEX II es una representación bastante buena del
conocimiento existente en el dominio del tráfico, por lo que su elección como base de representación
de conocimiento quedaría plenamente justificada.
43
Por otra parte, DATEX II ha sido orientado plenamente a la Web, tanto en la definición del modelo de
datos (UML y XML Schema) como en el de intercambio (servicios Web y WSDL) (Wei-feng, Wei, & Jian,
2008), lo cual aporta flexibilidad y adaptabilidad a las nuevas tecnologías utilizadas en la actualidad.
Figura 16: Ejemplo de retención representada mediante DATEX II
DATEX II ofrece además interesantes posibilidades de publicación (Cowan, Sultan, & Burrows, 2008) e
intercambio de información (Raines & Rowley, 2008), lo cual será aprovechado para llevar a cabo la
evolución de sus modelos a un escenario basado en Web Semántica.
Aunque el presente apartado podría extenderse analizando las características técnicas de DATEX II, ya
que serán utilizadas en el desarrollo del trabajo, por la naturaleza investigadora del trabajo parece
mejor no detenerse en este análisis técnico. En cualquier caso, en el Anexo I se incluye una referencia
rápida sobre los modelos de datos e intercambio de DATEX II. Para una información más detallada sobre
esta especificación es posible acceder directamente a la documentación oficial de DATEX II en su sitio
Web: http://www.datex2.eu (DATEX II TC, 2007).
44
2. Estado del arte
2.3
APLICACIÓN DE LA WEB SEMÁNTICA A LOS ITS
Una vez realizada una revisión bibliográfica de los dos dominios de investigación que ocupan el presente
trabajo, es necesario realizar una nueva búsqueda más especializada en la que se comente el uso en el
ámbito específico del presente proyecto de investigación.
Sin duda la mejor referencia en esta materia es la tesis (Samper Zapater J. J., 2005), así como las
publicaciones que de ella derivaron. En la citada tesis se trabajó de forma amplia con muchos de los
conceptos que se han comentado en los dos apartados anteriores, y se desarrollaron otros muchos que
exceden del ámbito del presente proyecto.
En este trabajo se desarrolló desde cero una ontología de información de tráfico, y se definió una
arquitectura basada en servicios Web semánticos que permitiera la interacción con la información
contenida en el sistema. Se profundizó especialmente en el concepto de emparejamiento semántico,
familia de algoritmos que consisten en la búsqueda de dos descripciones de servicios que comparten
gran parte (o toda) su especificación. Otro concepto que interesante que apareció fue la determinación
de profiles de publicación de los servicios Web semánticos. Estos profiles incluyen una descripción
detallada de las capacidades de un servicio, facilitando el acceso a los clientes que quieran consumir la
información del servicio.
En el apartado Trabajo Futuro de esta tesis se abrían nuevas líneas de investigación que han sido
tomadas en cuenta en el presente proyecto, en especial el factor multimodal para la presentación de
información al usuario y la posibilidad de especificación de perfiles avanzados de preferencias de
usuarios. Estas ideas ya han sido tenidas en cuenta para el planteamiento de objetivos del presente
trabajo. En cualquier caso, será posible aprovechar muchas de las metodologías, técnicas y herramientas
utilizadas en la mencionada tesis, facilitando la toma de muchas de las decisiones que suelen ir
apareciendo en el desarrollo de un trabajo de estas características.
En cuanto a las publicaciones que derivaron de la aparición de esta tesis destaca (Samper Zapater J. J.,
Tomás, Martinez, & Berg, 2006), artículo que explica la ontología de tráfico desarrollada en la tesis y la
engloba en una arquitectura multiagente que permite el intercambio de información mediante servicios
Web semánticos. Basándose en este artículo, en (Zhai, Yu, Liang, & Jiang, 2008) se propone otra
ontología de tráfico que introduce lógica difusa para la descripción de algunas variables lingüísticas
habituales en tráfico. Un ejemplo que utilizan es la velocidad de un vehículo, en muchas ocasiones no es
posible determinar la velocidad exacta del vehículo, o simplemente no es necesaria esta representación.
Valores difusos como “rápido” o “lento” podrían ser suficientes para una gran cantidad de casos de uso.
En el artículo se incluye esta información categórica en las tripletas RDF generadas que albergan la
información de tráfico, y posteriormente acceden a estas bases de conocimiento mediante Sesame,
(Aduna-Software, 2009), un almacén de tripletas RDF de alto rendimiento.
Otra tesis que trabajó intensamente la aplicación de semántica a los ITS fue (Tomás López, 2006). En
este trabajo se construyó otro sistema multiagente, esta vez más orientado a la gestión del tráfico, por
lo que estaría ligeramente más alejado de los objetivos planteados. Sin embargo, se considera
especialmente interesante la metodología aplicada para el modelado del dominio del tráfico
interurbano y su posterior utilización en un entorno multiagente basado en la plataforma JADE (JADE
community, 2009), por lo que servirá también como referencia para parte del trabajo que se pretende
realizar.
45
2.4
MODELIZACIÓN SEMÁNTICA DE USUARIOS
La modelización de usuarios es una técnica usada para la personalización de aplicaciones en la cual se
intenta representar en la medida de lo posible todas las características asociadas a un usuario.
La aplicación de semántica ha facilitado en los últimos tiempos la modelización de estas características
de forma clara, permitiendo a otras aplicaciones utilizar esta información para adaptar las respuestas a
las preferencias y características de los usuarios (Houben, Aerts, Aroyo, Sluijs, Rutten, & Bra, 2005).
Un concepto importante dentro de la modelización de usuarios es el perfil de usuario. Para que un perfil
de usuario pueda ser de utilidad con otros sistemas, se requieren que especifique todas sus preferencias
basándose en tres categorías principales:
•
Características estáticas: Datos técnicos que no vayan a variar de forma continua. Como ejemplos,
para personas parámetros técnicos podrían ser el nombre, DNI, correo electrónico, fecha de
nacimiento o dirección; mientras que para máquinas el nombre, número de serie, modelo de
dispositivo, capacidades técnicas podrían representar las características de un usuario. Existe un
buen número de modelos semánticos desarrollados para este fin, entre los cuales destaca la
ontología de uso general Friend Of A Friend ó FOAF (foaf project, 2009).
•
Preferencias subjetivas: Una preferencia se refiere a un interés o desinterés sobre algún elemento.
Este elemento referenciará otros modelos existentes, posiblemente adjuntando un grado de interés
(Sinner, Kleemann, & Hessling, 2004).
•
Características contextuales: Datos técnicos que varían en función de las acciones que esté
llevando a cabo un usuario. Por ejemplo, para una persona, su posición GPS o si se encuentra
involucrado en alguna tarea (por ejemplo, si está conduciendo cualquier sistema debería evitar
ofrecer la información de forma visual) (Houben, Aerts, Aroyo, Sluijs, Rutten, & Bra, 2005).
Existen además algunos frameworks que agrupan estos conjuntos de características. Por ejemplo, en
(Ghosh & Dekhil, 2008) se propone el Semantic User Profile management framework (SUPER), que reúne
en una ontología OWL una gran cantidad de propiedades sobre los gustos y preferencias de un usuario,
además de otros detalles estáticos.
Especial atención merecen además la incorporación de conceptos imprecisos (lógica difusa) para la
caracterización de algunos parámetros del usuario. En (Liu, 2007) se incorpora este tipo de lógica en un
sistema basado en agentes para establecer perfiles de compradores (clasificación dinámica). Esta
introducción de lógica difusa ofrece una mayor flexibilidad en la representación de conceptos, aunque
obliga ajustar algunos parámetros de las ontologías con las que se trabaja para la adecuación a los
requerimientos de la lógica difusa. En el Anexo II se realiza un rápido repaso sobre las generalidades de
esta parte de la lógica y su aplicación a las ontologías y al formato de descripción OWL.
Otro aspecto que se deberá tener en cuenta es el formato de publicación de información. Cada perfil de
usuario puede llevar asociado uno o varios formatos de representación soportados, cada uno con sus
características y limitaciones. Para la publicación de información es necesaria, por lo tanto, la
elaboración de conversores de información que adapten la información que se pretende publicar a los
parámetros técnicos y preferencias del usuario.
Una solución interesante de esto fue el objeto de la tesis (Carrillo Zambrano, 2004), donde se utilizaba
un formato intermedio (basado en semántica) para describir los elementos genéricos de un documento
de presentación al usuario, particularizándose los elementos finales (tamaño de texto, resolución de
imágenes) para cada perfil cliente, teniendo en cuenta los parámetros técnicos de cada dispositivo.
46
2. Estado del arte
2.5
SISTEMAS DE ADQUISICIÓN DE INFORMACIÓN SEMÁNTICA
Aunque lo normal es que cada sistema basado en semántica se construya su propio sistema de
adquisición, en los últimos años se ha intentado proponer modelos genéricos para la extracción de
información de modelos basados en semántica.
En (Zhang & Li, 2008) se propuso un sistema para la extracción de información almacenada en un
modelo semántico, incluyendo un sistema de clasificación de información y una interfaz de usuario para
la interacción con el sistema.
Otra publicación en la misma línea, buscando una visión más aplicada, fue (Shao, Li, Du, & Qi, 2008), en
la que, a partir de una base de datos empresarial y una pasarela de integración, se construía una
aplicación multimodal para la interacción con información semántica, permitiendo exportación de
información en múltiples formatos e interacción con usuarios.
Por último cabe destacar la posibilidad de aprovechar algunas características de la lógica difusa para la
extracción de información de forma imprecisa, acercando de esta forma esta extracción de información
al lenguaje humano. En (Zhai, Shen, Liang, & Jiang, 2008) y (Zhai, Cao, & Chen, Semantic information
retrieval based on fuzzy ontology for intelligent transportation systems, 2008) se utilizó una arquitectura
genérica para la extracción de información semántica, incluyendo en las ontologías objeto algunos
atributos definidos de forma borrosa. En las consultas que se plantearon se incluyeron cláusulas
referidas a estos atributos difusos, permitiendo de esta forma la extracción de la base de conocimiento
con buenos resultados.
47
3. Semántica aplicada a DATEX II
3
SEMÁNTICA APLICADA A DATEX II
Después del análisis y estudio del marco de trabajo basado en Web Semántica de los apartados
anteriores, es posible comenzar con la evolución del modelo DATEX II actual a un modelo basado en
ontologías.
La versión actual de DATEX II5 es la versión 2.0 RC1, que será la utilizada para realizar la adaptación al
modelo semántico. Una posibilidad que fue considerada fue el uso de la versión 1.0 (actual versión
estable del modelo), sin embargo esta versión contiene algunos fallos y no es del todo completa, por lo
que esta opción fue descartada en detrimento de la última versión. Se estima que esta versión
representará mejor el conocimiento disponible en materia de tráfico.
En los siguientes apartados se realiza un recorrido de cómo se ha llevado esta adaptación al modelo
semántico, comenzando con la actualización de la ontología DATEX II que se dispone a la última versión
del modelo, desarrollando un prototipo de pasarela que se encarga de la conversión de información
DATEX II en el modelo basado en semántica. Por último se definen algunas consultas de acceso a la
información para comprobar la validez de la pasarela.
3.1
ACTUALIZACIÓN DE LA ONTOLOGÍA DATEX II
Como ya se ha comentado, para llevar a cabo esta adaptación se cuenta con un modelo ontológico ya
elaborado realizado a partir de una versión previa a DATEX II 1.0 (aunque muy similar a esta versión
estable) en (Canós Gandía, 2003). Este modelo, descrito en OWL y por tanto compatible con Protégé,
será tomado como base para dicha adaptación, ahorrando así parte del trabajo, debido a la similitud
entre versiones.
En concreto esta actualización se ha atacado desde cuatro vertientes:
•
Actualización de los cambios aparecidos en la nueva versión de DATEX II, en general añadido de
tipos nuevos y extensiones y modificaciones en los diccionarios de datos.
•
Resolución de errores, principalmente en la definición de algunas propiedades, rangos y dominios.
•
Ampliación de las jerarquías. Para reducir la complejidad del modelo, DATEX II especifica
únicamente unos pocos tipos generales y amplía los detalles de estos tipos mediante atributos type,
definiendo una enumeración que particulariza el evento producido. Por ejemplo, en DATEX II se
define un atropello de una persona como un objeto de la clase Accident, con AccidentType
collisionWithPerson. En la ontología de la cual se partía se había heredado esta técnica de ahorro,
sin embargo parece adecuado completar totalmente las jerarquías según estos tipos, aumentando
de esta la expresividad semántica de la ontología desarrollada. Por ejemplo, en la ontología original,
para obtener todos los accidentes de tipo Collision, era necesario obtener primero todas las
instancias de Accident y después ir mirando uno a uno qué tipos se corresponden con collision. Se
ha perdido de esta forma el poder semántico del modelo. En el nuevo modelo, es tan fácil como
obtener las instancias de CollisionAccident.
5
El estado actual a mediados de 2009 es que existe una versión candidata a estandarización, aunque todavía se
espera la posible llegada de cambios propuestos por los países miembros, por lo que no se descarta que puedan
aparecer nuevas versiones hasta final de 2009, fecha en la que el modelo será llevado finalmente a estandarización
y se etiquetará como versión estable 2.0. En cualquier caso, en estas nuevas versiones no se esperan modificaciones
profundas en el modelo, sólo pequeños cambios como resolución de erratas en comentarios o la aplicación de
convenciones para el nombrado de variables.
49
•
Actualización a la versión OWL 2. Migración a Protégé 4, que tiene soporte de esta reciente versión
de OWL, con nuevas posibilidades.
Las siguientes figuras contienen capturas obtenidas mediante la aplicación Protégé. En las dos primeras
se reflejan algunas jerarquías principales de la ontología (recogidas mediante la utilización del plugin
OntoViz) y la tercera representa un vistazo general de Protégé con la ontología DATEX II cargada.
Figura 17: Jerarquía para la clase general Situation (3 niveles)
50
Figura 18: Jerarquía para la clase Accident
Figura 19: Captura de la ontología DATEX II cargada en Protégé 4
Por último, merece la pena destacar el uso de la herramienta WebProtégé para la visualización rápida de
la ontología de forma descentralizada (vía Web), cuyos detalles aparecen en el Anexo IV, apartado IV.1.
51
3.2
PROTOTIPO DE PASARELA DATEX II – DATEX II SEMÁNTICO
Mediante el modelo ontológico se han descrito las jerarquías, propiedades y restricciones que deberá
tener la información contenida en él. Este modelo ontológico es, por lo tanto, la base para comenzar a
trabajar sobre el modelo semántico planteado. Protégé 4 dispone de utilidades para la exportación de la
ontología en diferentes formatos, aunque en este caso el elegido fue RDF/XML, ya que es el que más
compatibilidad proporcional para la mayoría de frameworks.
Para comenzar a obtener información representable en el modelo ontológico se optó por construir una
pasarela que efectuara la transformación de la información según el modelo DATEX II al modelo
semántico. De esta forma, el sistema asegura la compatibilidad con el resto de la red DATEX II: desde el
punto de vista de un usuario que quiere intercambiar información mediante DATEX II, utilizaría su
interfaz habitual, y la información se replicaría automáticamente en el modelo semántico, por lo que
realmente este modelo semántico estaría ampliando y no substituyendo la funcionalidad del modelo
original.
El presente prototipo recoge la información contenida en un fichero DATEX II proveniente de una URI
conocida, y traduce la información, generando modelos en memoria que más tarde podrán ser
almacenados en ficheros o bases de datos. Para llevar a cabo esta generación de modelos se ha utilizado
el framework Jena (Jena team, 2009) en su versión 2.6.
Mediante la utilidad schemagen (Jena team, 2008), se generó a partir del fichero OWL de la ontología
desarrollada en el apartado anterior un fichero que contenía un listado de clases y propiedades
utilizando ya el API de Jena, de forma que la generación de los recursos, el instanciamiento de clases o la
inclusión de propiedades en las clases resultaba una tarea tan sencilla como hacer referencia a un
objeto estático de la clase generada por la utilidad.
Figura 20: Ejemplo de propiedades y tipos generados mediante schemagen
Utilizando este conjunto de recursos y teniendo en cuenta los tipos y subtipos de DATEX II, fue
construyéndose un modelo ontológico en memoria, al que posteriormente se adjuntaron las reglas de la
ontología desarrollada, generando finalmente un modelo de inferencia listo para razonar. El razonador
elegido para ello fue Pellet 2.0 (clark & parsia, 2009), debido a las funcionalidades que ofrece. Por
ejemplo, una característica muy interesante fue la validación de los datos RDF generados contra el
esquema OWL, prestando explicaciones de los fallos producidos en caso de inconsistencia, lo cual ayudó
a la depuración del código fuente.
En esta versión se han traducido dos tipos de datos DATEX II (AbnormalTraffic y Accident), así como dos
tipos de localizaciones: localizaciones de tipo Alert-C y localizaciones basadas en coordenadas
geográficas (véase Anexo I - DATEX II). Además, otra información básica de control (fechas de registro,
identificadores) ha sido incluida mediante el uso de las propiedades destinadas a ello en la ontología.
El resultado final es un modelo ontológico en memoria que será objeto de testeo y evaluación en
apartados posteriores. Llegado a este punto merece la pena destacar que Jena ofrece utilidades para su
52
serialización, tanto en ficheros como en base de datos, que podrían ser utilizados para hacer
persistentes los modelos traducidos, lo cual podría ser interesante en un futuro para la construcción de
sistemas que se apoyen en este modelo.
Todo este desarrollo ha sido integrado utilizando herramientas comunes de proyectos software, tales
como Eclipse, JUnit y Maven. La Figura 21 contiene un ejemplo del entorno de trabajo utilizado.
Figura 21: Entorno de trabajo basado en Eclipse para el desarrollo de la pasarela de DATEX II al modelo ontológico
3.3
GENERACIÓN DE CONSULTAS
Una vez generado el modelo ontológico con los datos y el esquema, es posible comenzar a explotar la
información contenida en el modelo utilizando las APIs que ofrece Jena para interactuar
semánticamente con la base de conocimiento.
En concreto, se propone definir un conjunto de consultas que extraerán información relevante del
modelo y que tendrán dos cometidos posteriores: servir como base para una futura plataforma de
filtrado de información y evaluar, mediante la implementación de estas consultas en las diferentes APIs
disponibles, la complejidad y eficiencia de cada una de ellas.
Las consultas que se deberán satisfacer se refieren a búsquedas de escenarios y situaciones en base a
algunos criterios (por identificador, tipo, fecha, o con características especiales como objetos peligrosos
involucrados), además de cálculos sobre localizaciones para determinar relaciones entre situaciones.
Para la evaluación del modelo se pretende probar estas consultas utilizando las siguientes APIs:
•
RDF API: Consulta directa sobre el grafo de tripletas RDF.
•
Ontology API: Consulta sobre el modelo de ontología de alto nivel, basado en clases, instancias.
•
SPARQL: Lenguaje de consulta de la Web Semántica.
53
Además, parece adecuado en este caso, comparar los resultados obtenidos con los que se obtendría
trabajando con el modelo original no semántico, utilizando XmlBeans (XMLBeans Community, 2009)
como framework de acceso a datos.
Para llevar a cabo la posterior evaluación de este conjunto de consultas fue definida una clase abstracta
que todos los ficheros de consulta debían implementar.
public abstract class TestableQuery {
protected OntModel completeModel;
protected OntModel dataModel;
protected Model basicDataModel;
protected Model basicCompleteModel;
protected D2LogicalModelDocument doc;
protected int dataset;
public final void configureTests (OntModel completeModel, OntModel dataModel,
D2LogicalModelDocument doc, int dataset) {
this.completeModel = completeModel;
this.dataModel = dataModel;
this.doc = doc;
this.dataset = dataset;
this.basicDataModel = dataModel;
this.basicCompleteModel = completeModel;
}
public void initializeTests () {
}
public
public
public
public
abstract
abstract
abstract
abstract
void
void
void
void
testRDFAPI();
testOntologyAPI();
testSPARQL();
testXmlBeans();
public static void executeQuery (String queryString, Model model) {
Query query = QueryFactory.create(queryString);
// Execute the query and obtain results
QueryExecution qe = QueryExecutionFactory.create(query, model);
ResultSet results = qe.execSelect();
// Output query results
ResultSetFormatter.out(System.out, results, query);
// Important - free up resources used running the query
qe.close();
}
}
De esta forma, cada vez que se quiera registrar una nueva consulta para evaluación, es tan sencillo
como extender de esta clase abstracta e implementar cada uno de los métodos requeridos según la
consulta deseada, utilizando los atributos protected puestos a disposición de estas clases derivadas.
Esta clase abstracta provee, además, un método estático de ejecución de consultas SPARQL
(executeQuery), con lo que la ejecución de consultas quedaría reducida a una llamada a este método,
simplificando de esta forma el desarrollo. La idea es utilizar esta función después de haber obtenido la
consulta de un fichero separado, facilitando el desarrollo, testeo y la posterior mantenibilidad de dicho
código.
Cabe destacar en este punto la herramienta Joseki, que contiene un procesador de consultas SPARQL, y
que fue utilizada para la validación funcional de las consultas. En el Anexo IV, apartado IV.2 se reúnen
más detalles sobre dicha utilidad.
Las especificaciones de todas las consultas planteadas se describen en el Anexo II y se identificarán de
aquí en adelante mediante un índice QX, siendo X el número de consulta.
54
4. Plataforma de publicación
4
PLATAFORMA DE PUBLICACIÓN
En el capítulo anterior se ha desarrollado un modelo semántico de tráfico mediante el cual es posible
interactuar utilizando las diferentes APIs de acceso a datos disponibles.
Para el desarrollo de un sistema completo, resulta necesario envolver la información básica que ofrece
la base de conocimiento, ofreciendo interfaces avanzadas de acceso que consigan explotar la
información en base a unos requerimientos.
Desde un punto de vista funcional, la información de una base de conocimiento semántica sufriría las
siguientes transformaciones lógicas desde su extracción de la base de datos hasta la llegada al usuario
final del sistema:
•
Proyección: Acceso a la base de conocimiento y extracción de tripletas de algunos o todos los
atributos.
•
Composición: En el caso de acceder a más de una fuente de datos, esta transformación uniría todos
los conjuntos de datos en un único conjunto de tripletas.
•
Selección: En ciertos casos puede restringirse el acceso a la información mediante unos criterios
específicos que permitan resolver las consultas planteadas por el usuario.
•
Ordenación: Ordenación en base de los datos a un criterio.
•
Conversión de formato: La información semántica es totalmente manejable por máquinas, pero no
por usuarios finales, por lo que puede ser necesaria una conversión de tipo para que la información
pueda ser renderizada en aplicaciones interactivas dependientes de un formato.
En ocasiones, y dependiendo de los diseños e implementaciones utilizadas, algunas de estas fases
lógicas podrían entremezclarse o ejecutarse en órdenes diferentes. Por ejemplo, el lenguaje de consulta
SPARQL realizaría principalmente tareas de proyección, aunque en sus cláusulas es posible incluir
órdenes de composición, selección y ordenación de forma conjunta.
En los siguientes apartados se define una arquitectura de un sistema genérico para la explotación de
información semántica, aplicándolo posteriormente al dominio del tráfico para especificar un sistema de
explotación de información basada en la ontología desarrollada en el capítulo anterior. Para ello, se
definen los parámetros de los perfiles de usuario, así como algunas reglas semánticas derivadas,
describiendo con ello algunos perfiles habituales en el campo del tráfico.
4.1
ARQUITECTURA PARA LA PUBLICACIÓN DE INFORMACIÓN SEMÁNTICA
BASADA EN PERFILES
El primer paso para la definición de una arquitectura de este tipo es la especificación de forma detallada
de la información asociada al perfil de usuario.
Se definen de esta forma cuatro modelos semánticos, que cada usuario deberá completar mediante
servicios de acceso provistos por el sistema:
•
Characteristics: Características propias del cliente, de naturaleza estática. En este apartado se
pueden definir todos aquellos parámetros que no vayan a ser modificados con mucha asiduidad.
Algunas características que podrían resultar de especial relevancia serían las características técnicas
del hardware del cliente, los formatos que soporta, o sus parámetros de acceso en el caso de que
actúe como cliente pasivo (modo PUSH).
55
•
Context: Se refiere a propiedades aplicables sobre el usuario que puedan variar con una gran
periodicidad. Por ejemplo, la posición geográfica de una persona. De forma lógica, el resultado de
ciertas consultas debería poder ser adaptado en base a este tipo de propiedades variables.
•
Preferences: Preferencias en base a parámetros asociados a la presentación de columnas. Criterios
de ordenación, priorización de columnas, etc. Preferencias en base a la ontología objetivo,
definiendo restricciones y caracterizando la información en base a los gustos personales definidos
en cada perfil.
•
Concepts: Definiciones subjetivas sobre conceptos que se aplican directamente sobre la ontología
objetivo. Por ejemplo, para un conductor que va al trabajo, el concepto “cerca” no significaría lo
mismo que para un repartidor, que estaría interesado en abarcar una mayor extensión.
Un aspecto a destacar es la necesidad de soporte de información imprecisa para la definición de
muchos de los enunciados anteriores, por lo que para el desarrollo de estos modelos deberá ser tenida
en cuenta la generación de propiedades que puedan tomar valores difusos.
A continuación se define una arquitectura distribuida en unidades funcionales para la publicación de
información semántica basada en modelos semánticos para la definición de preferencias de usuario.
Figura 22: Arquitectura funcional para la explotación de información semántica basada en perfiles
Además del conjunto de datos que definen las preferencias del cliente, y que se consideran descritas de
forma offline (excepto Context, debido a su naturaleza dinámica), se definen los siguientes elementos en
el sistema:
•
Client Manager: Recoge la consulta del cliente y se encarga de distribuir las tareas al resto de
unidades funcionales para procesar la respuesta.
56
•
Conversion: Decide cuál será el formato de presentación de la información en base a los
parámetros definidos en el perfil del usuario, encargándose de que dicha transformación sea
efectuada.
•
Selection: Se encarga de seleccionar y filtrar la información recibida en función de las reglas
definidas en las preferencias de usuario, teniendo en cuenta el contexto de usuario.
•
Displayer: Tiene en cuenta algunas preferencias genéricas de usuario para la presentación de
información. Este componente deberá tener en cuenta entre otras las ordenaciones verticales (de
datos) y horizontales (de columnas) que proponga el usuario.
•
Composition: Recoge la consulta final desde el Client Manager, y efectúa la consulta a todas las
fuentes de información con las que deba interactuar. Una vez recibida la información, la integra en
un único conjunto.
•
SIR (Service Information Retrieval): Sistema externo encargado de acceder a la fuente de
información y ejecutar la consulta de extracción de información.
•
Context Updater: Sistema autónomo encargado de actualizar las definiciones sobre el contexto en
base a los cambios de estado que sufra el usuario.
Como ya se ha comentado, después del lanzamiento de una consulta por parte del cliente, el Client
Manager se encargaría de descomponer en tareas más pequeñas todas las acciones necesarias para la
implementación de la consulta. Un posible algoritmo para llevar a cabo esta tarea sería el siguiente:
a)
Preparación:
1
Comprobación de que todos los componentes están disponibles y en caso contrario iniciar
un proceso de descubrimiento.
2
Llamada a Displayer para la introducción en la consulta de criterios de selección de
atributos y ordenación en las tuplas en el caso que sea posible.
b) Procesamiento:
c)
1
Llamada a Composition con la consulta obtenida en el paso anterior.
2
Para cada fuente de datos configurada, llamar al SIR de la fuente de datos y recoger los
resultados extraídos de la fuente en base a la consulta planteada.
3
Integración de toda la información devuelta en un único elemento.
4
Llamada a Selection para la valoración de los mensajes teniendo en cuenta las preferencias
de usuarios y el contexto de cada usuario.
Presentación:
1
Llamada a Displayer para la ordenación de mensajes en base a los criterios definidos por el
usuario. En este paso podría considerarse el filtrado de aquellos mensajes que no
cumplieran unos requisitos mínimos propuestos por el cliente o que no sean compatibles
con algunas de sus especificaciones (por ejemplo, máximo de mensajes).
2
Determinación del formato de salida en Conversion teniendo en cuenta las capacidades del
cliente, las preferencias del usuario, el contexto en el que se encuentra, y los conceptos
que se definen sobre estos elementos.
3
Implementación de la transformación de formato y envío de la información al usuario.
57
4.2
PERFILES DE EXPLOTACIÓN DE INFORMACIÓN DE TRÁFICO
Una vez definidas las características básicas de una arquitectura de publicación de información
semántica, es posible plasmar en el caso de uso objeto del presente trabajo una primera aproximación
en la definición de un sistema de explotación de información de tráfico.
En primer lugar, será necesaria la definición de los parámetros necesarios en cada una de las categorías
del perfil del cliente, para facilitar así la posterior extracción de información de la base de conocimiento
de los parámetros de usuario.
4.2.1 ESPECIFICACIÓN DE PARÁMETROS
Para la definición de estos parámetros se usarán las categorías anteriormente mencionadas además de
algunas otras auxiliares que efectúan una primera división semántica sobre la información asociada a un
perfil de usuario.
Resources
Conjunto de recursos estáticos utilizados por dispositivos, aplicaciones, etc.
Figura 23: Modelo para la ontología Resources
Se ha definido únicamente el acceso a Internet como recurso, por las implicaciones que tiene en la
posterior representación de formatos (algunas aplicaciones podrían no funcionar sin este recurso), sin
embargo sería posible ampliar fácilmente este listado de recursos.
Services
Caracteriza servicios externos al sistema, posiblemente servicios de terceros que es necesario catalogar
porque van a participar en el sistema de forma indirecta para algunas tareas.
58
Figura 24: Modelo para la ontología Services
Aunque no se ha especificado en detalle, el parámetro informacionConexion contendría un enlace a la
especificación del servicio, utilizando para ello recursos semánticos definidos por ejemplo mediante
ontologías de definición de SWS como OWL-S.
Al igual que en el caso anterior, sólo se ha especificado un tipo de servicio ServicioTraduccion, que se
encargaría de la conversión de información de tráfico de un formato a otro. En cualquier caso, sería
posible añadir nuevos tipos de servicio para adecuar el modelo a los problemas que se planteen.
Translation Directory
Listín de servicios de traducción, incluyendo información sobre los formatos de representación de
información de tráfico, así como de las aplicaciones encargadas de esta representación.
Figura 25: Modelo para la ontología Translation Directory
En información adicional para un formato es posible añadir recursos adicionales de descripción, como
enlaces Web o recursos semánticos que describan el formato.
La necesidad de Internet es una característica que representa si una aplicación necesita o no de
conexión a Internet para su funcionamiento. Por ejemplo, un visor de texto plano no necesitaría de
Internet, mientras que una aplicación basada en mapas como Google Maps necesitaría conexión a
Internet para la descarga de los mapas y otra información geográfica.
59
Para una transformación se define un atributo calidad, que determina una estimación de la calidad en la
traducción hecha por un servicio. Este valor deberá ser obtenido una única vez al conectar con el
servicio de traducción y oscilará entre 1 (sin pérdida de información) y 0 (se pierde toda la información).
Debido a las características intrínsecas de los formatos (para obtener un formato es posible convertir a
formatos intermedios), se define además la siguiente propiedad transitiva entre las transformaciones de
formato para transformaciones de tipo compuesto:
Sea una función que transforma un objeto del formato
formato a , de tal forma que:
Es posible construir una función
funciones:
que transforme de
a
a
y
otra función que transforma del
como una composición de las otras dos
Sin embargo, estas transformaciones intermedias tienen como efecto secundario la pérdida de
información (en la práctica cualquier transformación entre formatos tiene una pérdida de información).
Formalmente se tiene:
’
El atributo calidad del servicio de traducción dictará lo cercana o lejana que estará la traducción entre la
información original y la información traducida. Sin embargo, el anidamiento amplifica esta pérdida de
información, propagando los posibles errores que puedan producirse. Para obtener una medida de la
pérdida de información total será necesario controlar el anidamiento en la composición de funciones.
Siendo n el número de pasos necesario para llevar a cabo la transformación (nivel del anidamiento de
funciones).
Estas medidas ayudarán al agente Conversion a elegir el mejor servicio de traducción, eligiendo aquel
camino que minimice la probabilidad pérdida de información. Su trabajo se limitará a resolver un
problema clásico de caminos mínimos entre nodos. Otra de las tareas necesarias para el correcto
funcionamiento de este directorio será la comprobación periódica de que los servicios incluidos en este
listín son válidos.
Characteristics
Características básicas del dispositivo, incluyendo una como lista de formatos soportados.
60
Figura 26: Modelo para la ontología Characteristics
El atributo maximoMensajes introduce un número máximo físico para el número de mensajes. En caso
de no especificarse se considera que no hay limitación en esta propiedad.
Context
Datos contextuales para el cliente que será necesario ir actualizando de forma periódica.
Figura 27: Modelo para la ontología Context
Se incluyen dos clases asociadas a las conexiones a los servicios y al recurso Internet, para representar
en tiempo real cual sería la calidad de estos elementos.
Concepts
Reglas definidas sobre la ontología DATEX II y la ontología Context. En este apartado se definen todos
aquellos conceptos aplicados a la ontología objeto para determinar una medida de la importancia de un
suceso de tráfico.
61
Figura 28: Modelo para la ontología Concepts
Una característica muy importante es que, para todos los conceptos que especifiquen hechos
subjetivos (por ejemplo el concepto de distancia entre un suceso y el usuario depende del ámbito de
movimiento de cada usuario), se incluye una descripción por defecto de los conceptos de cada una de
las etiquetas lingüísticas. Sin embargo, cada usuario será libre de definir sus propios elementos,
variando las cotas o incluyendo modificadores lingüísticos, lo cual aportará una gran flexibilidad al
modelo.
Todas las definiciones se especifican de formalmente mediante 5-tuplas según el método original
(Zadeh, Fuzzy Sets, 1965). Las gramáticas asociadas no son mencionadas explícitamente, pero
básicamente sería una especificación formal de las gramáticas necesarias para la formación de las
etiquetas lingüísticas y de sus modificadores y operadores.
La primera característica para la descripción de la relevancia de un suceso es la distancia al usuario.
Para conseguir comprimir al máximo la información y debido a que no existen valores corte adecuados,
se utiliza una aproximación borrosa para expresar el significado de esta variable.
Se define la variable lingüística “Distancia” de la siguiente forma:
62
Se define M como un conjunto de funciones de pertenencia por defecto de la forma:
Figura 29: Funciones de pertenencia para las etiquetas lingüísticas de la variable Distancia
Por otra parte, otra característica importante para los usuarios debería ser su validez, el tiempo que
llevan activos. En general, un suceso que lleva poco tiempo activo será más propenso a presentar
inestabilidades, por lo que habría que prestarle especial atención.
Una valoración concreta se obtiene de la resta de la hora actual y la hora del suceso, expresando esta
diferencia en minutos.
Se define la variable lingüística “Validez” de la siguiente forma:
63
Se define M como un conjunto de funciones de pertenencia por defecto como sigue:
Figura 30: Funciones de pertenencia para las etiquetas lingüísticas de la variable Validez
Otra característica importante sería la prioridad de cada suceso. Esta prioridad vendría dada por las
administraciones que generen el mensaje, e indicaría un juicio de la prioridad de un mensaje que
tendría una cierta relevancia, al ser propuesta por un experto en tráfico (policías, operadores, etc.).
Este atributo obligaría a la ampliación de la ontología DATEX II para poder incluir un valor para esta
prioridad.
Se define la variable lingüística “Prioridad” de la siguiente forma:
64
Figura 31: Funciones de pertenencia para las etiquetas lingüísticas de la variable Prioridad
Para la ontología DATEX II ya existen algunos valores que se expresan de forma categórica, y que serían
fácilmente adaptables a una aproximación difusa que podría ayudar normalizar y mejorar la información
que ofrecen. A continuación se citan algunos de estos valores que se prestan especialmente a una
aproximación borrosa debido a que los valores categóricos que representan deberían ser alcanzados de
forma suave (pudiendo tomar valores intermedios) y no de forma abrupta (perteneciendo estrictamente
a uno u otro):
•
Delays: Atributo utilizado para indicar el retraso en la salida de un servicio de transporte. Se
categoriza de la siguiente forma: {veryLongDelays, delays, longDelays}, aunque añade la posibilidad
delaysOfUncertainDuration para indicar el desconocimiento de la variable.
•
ProbabilityOfOccurrence: Probabilidad de que un hecho suceda. Tiene aplicación en la planificación
de sucesos. Puede tomar los valores {certain, probable, riskOf, improbable}.
•
RoadworksDuration: Se utiliza para indicar el tiempo estimado de finalización de una obra. Se
indica un valor entre {shortTerm, mediumTerm, longTerm}.
•
Urgency: Parámetro definido por la administración para indicar una consideración de lo urgente
que es un evento. Actualmente se indica en forma de flag que se activa si el evento es urgente.
•
Direction: Utilizado para definir la dirección de un evento, en el método de localizaciones TPEG se
indica mediante una categorización según los puntos cardinales (norte, sur, este y oeste y sus
intermedios).
A continuación se establece una relación de otros posibles parámetros que podría ser interesante añadir
para facilitar la descripción de la información asociada a algunos mensajes:
•
Intensidad de un evento meteorológico: Para definir la intensidad de un evento meteorológico
ahora mismo es necesario ofrecer un valor concreto de una medida tomada (litros recogidos,
velocidad del viento, etc.). Podría definirse una variable lingüística que permitiera imprecisión al
introducir este parámetro.
65
•
Impacto de un evento: Aunque DATEX II permite definir un impacto de diferentes formas (número
de carriles obstruidos, porcentaje de capacidad perdida o incluso variables categóricas para definir
que la carretera está parcial o totalmente bloqueada), en muchos casos será imposible determinar
este impacto de esta forma. Una posible solución sería la inclusión de una variable mediante la cual
simplemente se etiquetara el impacto con un valor difuso {ALTO, MEDIO, BAJO}.
•
Número de personas en un evento: Aunque actualmente no se especifica nada en DATEX II ni en la
ontología, sería interesante un atributo que indicase el número difuso de personas {ALTO, MEDIO,
BAJO} involucrado en un suceso de tipo Activity, ya que la prioridad de este suceso será distinta
para los grandes eventos que para una exhibición. Sería interesante aquí (en especial para eventos
de tipo público) la inclusión de reglas teniendo en cuenta el país donde se producen (introduciendo
además una nueva propiedad para la ontología Context), reflejando la realidad de las preferencias
de cada país6 por los eventos públicos y ofreciendo una información más precisa sobre el evento
que se está produciendo.
Preferences
Criterios generales de ordenación y de priorización de campos, además de algunas reglas sobre los
elementos aplicados a conceptos.
Figura 32: Modelo para la ontología Preferences
La preferencia de tipo PreferenciaRegla define algunas reglas personalizadas que se aplican sobre
variables lingüísticas definidas en la ontología Concepts.
6
Por ejemplo, hablando de eventos deportivos, está claro que a una carrera ciclista asistirá un número muchísimo
mayor de personas en Francia que en Portugal, o en Lituania se habría de esperar una mayor afluencia de público
en los partidos de baloncesto que en otros países.
66
Es necesario incluir en este punto una definición del conjunto difuso Importancia (utilizado en
PreferenciaNivelInteres y en las reglas de preferencias), que obtiene una medida del nivel de interés del
mensaje obtenido a partir del conjunto de propiedades que se han definido en la ontología Concepts y
las preferencias de usuario.
Se define la variable lingüística “Importancia” como sigue:
Figura 33: Funciones de pertenencia para las etiquetas lingüísticas de la variable Importancia
Los valores de las variables lingüísticas se obtendrán como resultado de reglas resultantes de la
aplicación entre los conceptos definidos por el usuario y las preferencias asociadas a cada ítem. Por
ejemplo, si un usuario está interesado sólo en eventos próximos a su posición, definiría la siguiente
regla:
“Todos los sucesos a una distancia PRÓXIMA son eventos EXTREMADAMENTE IMPORTANTES”.
Además es posible combinar algunas reglas de las variables lingüísticas definidas anteriormente para
modelar las preferencias de los usuarios:
“Todos los sucesos con prioridad URGENTE o PRIORITARIO, con validez NUEVO o RECIENTE, y que estén
a una distancia PRÓXIMA o CERCANA son eventos IMPORTANTES”.
67
Será posible definir además reglas generales sobre tipos y características de la ontología DATEX II:
“Todos los sucesos de tipo Accidente son eventos IMPORTANTES”.
“Si hay objetos peligrosos implicados en un evento, estos eventos son MUY IMPORTANTES”.
Y por último, después de la ampliación de la ontología con parámetros adicionales, sería posible el
enunciado de reglas como:
“Las precipitaciones con Intensidad menor que INTENSA son eventos POCO IMPORTANTES”.
El componente Selection se encargará de la gestión de estas reglas, etiquetando los mensajes para que
Display discrimine posteriormente los mensajes que se mostrarán a los usuarios de los que no. Para
realizar esta última tarea, se tendrán en cuenta además dos variables de preferencia y una de
características (todas opcionales y no excluyentes):
•
Cota de importancia: Mediante el que el usuario define una cota por debajo de la cual no desea
recibir mensajes porque los considera no relevantes.
•
Cota de mensajes: Número máximo de mensajes que desea recibir el usuario. Puede servir para
limitar el número de mensajes recibidos aun en el caso de que su importancia relativa sea superior
a la cota de importancia que haya definido el usuario, con lo que se conseguiría una mayor síntesis
en la entrega de mensajes, eliminando la excesiva abundancia de información, que puede resultar
en muchos casos contraproducente.
•
Cota física de mensajes: Número máximo de mensajes que puede recibir el dispositivo del usuario.
El número final de mensajes que se presentará al usuario se puede calcular de la siguiente forma:
4.2.2 DEFINICIÓN DE PERFILES
En base a los parámetros definidos en el anterior apartado, se han especificado varios perfiles de
ejemplo, que podrían ajustarse para cada caso particular.
Se han especificado cinco perfiles de ejemplo:
•
Semántico: Ofrece toda la información de la ontología, sin transformar (formato RDF). Se encargaría
simplemente de ofrecer la información extraída de las bases de conocimiento.
•
Operador de Tráfico: Operador de la entidad encargada de la gestión de tráfico, mediante una
aplicación basada en mapas (formato KML). Estaría interesado en los eventos más activos (toda la
información que no sea demasiado antigua). Además, para una mayor eficiencia, se limitaría el
número de mensajes del mapa.
•
Analista de Tráfico: Examinaría listados ordenados por fecha (en PDF) de aquellos eventos antiguos
que hayan quedado activos. Su tarea consistiría en investigar si siguen abiertos o la administración
ha cometido un error y no se notificó la baja.
•
Policía: Mediante una aplicación móvil basada en mapas (KML), recibiría sólo aquellos eventos
nuevos con alta prioridad y que se encuentren bastante próximos a su posición. La idea es facilitar
la asistencia de estos policías a aquellos eventos más relevantes en su zona.
68
•
Servicio RDS-TMC: El contexto de uso de los servicios RDS-TMC suele ser la propia carretera,
mientras el usuario está conduciendo. Por lo tanto, se debería priorizar la información que esté
cerca del usuario, y que los eventos transmitidos no sean demasiado antiguos. Para minimizar la
comunicación con el usuario se establece una cota de importancia, limitando de esta forma la
entrada de información irrelevante, ya que son mensajes que podrían distraer innecesariamente al
usuario. El máximo físico de mensajes es 300 y el formato de entrada sería TMCXML7.
En la Tabla 1 se definen algunos de los parámetros aplicables a los perfiles de usuario que han sido
comentados en los párrafos anteriores.
Semántico
Operador
Analista
PRIORIDAD
TODAS
TODAS
TODAS
DISTANCIA
TODAS
TODAS
TODAS
VALIDEZ
TODAS
Máx. físico msj.
Máx. msj.
Cota importancia
Formato
Ordenación
Conexión
Internet
Policía
URGENTE y
PRIORITARIO
PROXIMO
RDF
-
NUEVO O
RECIENTE
100
KML
-
IMPORTANTE
PDF
FECHA
MÁS O MENOS
NUEVO
50
MUY IMPORTANTE
KML
-
NO
SI
NO
SI
ANTIGUO
RDS-TMC
TODAS excepto
INFORMACIÓN
PROXIMO O
CERCANO
NUEVO O RECIENTE
300
IMPORTANTE
TMCXML
NO
Tabla 1: Relación de perfiles de clientes de información de tráfico
4.2.3 DETERMINACIÓN DE REGLAS
A continuación se describen las reglas aplicables a información sobre contexto y a conceptos para los
perfiles definidos en el apartado anterior. Se especifican en lenguaje natural para mayor claridad,
aunque su transformación a lógica difusa sería bastante simple.
Regla por defecto (aplicable a todos los perfiles)
R0: Los eventos tienen importancia NORMAL
Semántico
No se definen reglas especiales
Operador de Tráfico
R_O1: Los eventos que son NUEVOS y tienen prioridad INFORMACIÓN son MUY IMPORTANTES
R_O2: Los eventos que son NUEVOS y que tienen prioridad distinta de INFORMACIÓN son EXTREMADAMENTE
IMPORTANTES
R_O3: Los eventos que son RECIENTES son MUY IMPORTANTES
R_O4: Los eventos que tienen prioridad INFORMACIÓN son POCO IMPORTANTES
R_O5: Los eventos que tienen prioridad AVISO y son ANTIGUOS son POCO IMPORTANTES
7
Formato de entrada en el cual se encapsularía toda la información de un evento de tráfico, de forma que fuera
compatible con los navegadores de abordo con soporte RDS-TMC. Actualmente se encuentra en fase de desarrollo
la descripción de dicho formato.
69
Analista de Tráfico
R_A1: Los eventos que son ANTIGUOS son IMPORTANTES
Policía
R_P1: Los eventos que son URGENTES son EXTREMADAMENTE IMPORTANTES
R_P2: Los eventos cuya prioridad es PRIORITARIO, que están PRÓXIMOS y que son NUEVOS son EXTREMADAMENTE
IMPORTANTES
R_P3: Los eventos que están PRÓXIMOS son MUY IMPORTANTES
R_P4: Los eventos que son NUEVOS son MUY IMPORTANTES
R_P5: Los eventos que son PRIORITARIOS son MUY IMPORTANTES
RDS-TMC
R_R1: Los eventos con prioridad URGENTE o PRIORITARIO y que están a una distancia PRÓXIMA son
EXTREMADAMENTE IMPORTANTES
R_R2: Los eventos con prioridad URGENTE, PRIORITARIO o NORMAL y que están a una distancia CERCANA son MUY
IMPORTANTES
R_R3: Los eventos que están a una distancia PRÓXIMA o CERCANA son IMPORTANTES
R_R4: Los eventos que son NUEVOS o RECIENTES son IMPORTANTES
Para el correcto tratamiento de estas reglas la implementación del sistema de gestión deberá tener en
cuenta que, en el caso de poder aplicar más de una regla, debería escoger la primera que satisfaga la
consulta planteada.
70
5. Resultados y discusión
5
RESULTADOS Y DISCUSIÓN
Una vez descrito el trabajo desarrollado en el presente proyecto, se procede a evaluar los resultados
obtenidos, realizando un análisis de los mismos con el objetivo de extraer conclusiones sobre los
experimentos realizados.
El presente apartado se va a estructurar según los módulos de trabajo realizados. En primer lugar, se
comentarán algunas características de la ontología desarrollada, comentando su complejidad y
proponiendo posibles mejoras y ampliaciones. La evaluación del modelo semántico construido a partir
de la ontología desarrollada constará principalmente del análisis y extracción de conclusiones sobre los
resultados obtenidos en base a la ejecución de las consultas propuestas sobre varios conjuntos de datos,
describiendo además algunos detalles relativos a la pasarela de traducción. Otro apartado que será visto
rápidamente será una demostración de las facilidades de RDF para la visualización de información. Por
último, se simulará un sistema basado en reglas para la discriminación y ordenación de mensajes en
base a los perfiles definidos en el capítulo anterior.
5.1
ONTOLOGÍA
Una de las métricas más directas para obtener una medida de la complejidad de una ontología es el
simple conteo del número de elementos que la forman. En la ontología de tráfico DATEX II se han
especificado un total de 650 clases diferentes, así como 251 propiedades definidas sobre estas clases,
representando de una forma relativamente extensa el conocimiento en el dominio del tráfico.
Como ya se esperaba (ver 3.1), se ha ampliado significativamente el número de clases de las jerarquías
respecto a la ontología original, debido principalmente a dos motivos: la eliminación de algunos
enumerados de naturaleza no categórica y su promoción como nuevas subclases (detallando así clases
de niveles superiores), y la presencia de un mayor número de subtipos y entidades en la nueva versión
del modelo de DATEX II.
(OWL-DL), pero más complejo
, subconjunto de
La expresividad DL obtenida fue
(OWL-Lite). Se han descrito métodos (Horrocks & Patel-Scheneider,
computacionalmente que
2004) que consiguen reducir una ontología de tipo OWL-DL a OWL-Lite, perdiendo expresividad a
cambio de ganar en eficiencia de procesamiento. En concreto consiguen bajar de costes NEXPTIME a
EXPTIME, por lo que en el caso actual, en el que no se ha conseguido una máquina no determinista en
tiempo polinómico, supondría una mejora considerable en el tiempo y memoria necesarios para
efectuar razonamiento sobre la ontología.
Para llevar a cabo el paso a OWL-DL bastaría con cambiar propiedades de tipo oneOf (selección entre
listas de categorías) por propiedades ad hoc para cada uno de los tipos. En cualquier caso, esta mejora,
así como el estudio de la aplicabilidad de perfiles que mejoren el razonamiento con la ontología (por
ejemplo perfiles todavía no estudiados en profundidad como OWL 2 EL o OWL 2 RL) quedarían como
trabajo futuro.
La ontología desarrollada consigue combinar de forma eficiente, por un lado, la representación
detallada del conocimiento en materia de tráfico, y por otro lado, la aproximación de un modelo
ontológico a otro modelo práctico existente basado en UML, facilitando de esta forma la integración en
sistemas reales, y permitiendo por lo tanto hacer utilizable la ontología en dominios más allá de la
investigación, como se comprobará en los siguientes apartados.
Por otra parte, otra característica del modelo ontológico desarrollado es que, al ser una ampliación del
modelo DATEX II original, preserva teóricamente la interoperabilidad con sistemas de naturaleza no
71
semántica, siendo posible la construcción de una pasarela inversa de transformación de la información
contenida en la base semántica al formato original del modelo DATEX II.
5.2
EVALUACIÓN DEL MODELO SEMÁNTICO
La presente evaluación busca justificar un posible uso del modelo semántico construido en ambientes
de Ingeniería del Software. Para ello, se intentará comparar, utilizando herramientas comunes en
ambientes de proyectos software, ciertos parámetros que ayuden a demostrar la validez o no del
modelo basado en ontologías, proponiendo futuras mejoras para facilitar la integración de otros
proyectos de dominios distintos.
Para llevar a cabo las pruebas se ha desarrollado una clase que crea un objeto
D2LogicalModelDocument (mediante XmlBeans) conteniendo el número de registros solicitado. Todos
los campos se introducen de forma aleatoria para asegurar la variabilidad de los datos, con las siguientes
particularidades:
•
Las fechas oscilan entre la fecha actual y un máximo de doce horas.
•
Existe la misma probabilidad para la creación de cada tipo DATEX II, y dentro de ella, la misma
probabilidad para cada tipo de forma que resulte lo más representativo posible el conjunto
generado. Por ejemplo, un Accidente puede tener involucrado un objeto, que a su vez podrá ser
etiquetado como peligroso, circunstancia que será tenida en cuenta para cubrir la casuística que se
pueda definir.
•
Se especifica una localización primaria Alert-C entre 1 y 1024 (ambos inclusive). La localización
secundaria se obtiene a partir de la primaria, pudiendo oscilar 32 puntos por encima o por debajo, y
siempre respetando las barreras.
Una vez creado en memoria el objeto D2LogicalModelDocument, se efectuaría una llamada a la API de la
pasarela, que traduciría este objeto en otro de tipo OntModel, disponible en la implementación de Jena,
que será sobre el que se desarrollen todas las pruebas.
Para el testeo de las evaluaciones contenidas en el presente apartado, se utilizarán tamaños de dataset
mediante una escala exponencial binaria8, llegando según los casos hasta datasets del orden de 1000
elementos. Esta medida se considera más que suficiente en un ambiente real, donde una administración
de tráfico podría tener a lo sumo 200 ó 300 eventos activos. Además, se repetirán las pruebas un
número suficiente de veces para que el test resulte representativo, debido a la gran variabilidad en la
gestión de los recursos de la máquina donde se ejecutan los test. Para minimizar la presencia de outliers,
se quitarán el valor máximo y mínimo de la serie obtenida.
5.2.1 EVALUACIÓN DE LA PASARELA
Para la evaluación del prototipo desarrollado se desarrollaron pruebas para medir el espacio en
memoria ocupado por el modelo ontológico, evitando otras medidas sobre el código fuente
desarrollado en la pasarela, ya que se ha considerado más importante la evaluación del desempeño del
propio modelo que el proceso de traducción en sí mismo.
La primera razón para ello es que no se ha considerado de especial relevancia la medición y posterior
optimización de la eficiencia de la pasarela debido a que el funcionamiento natural de esta pasarela es
8
Este hecho deberá ser tenido en cuenta especialmente en las gráficas que se representen, ya que cada ítem del eje
significará que se ha duplicado el tamaño de los dataset. Para facilitar la correcta visualización de las gráficas se
utilizarán escalas exponenciales también en el eje de ordenadas.
72
el trabajo de forma offline respecto a los actuales sistemas DATEX II, obteniendo información cada cierto
tiempo, e introduciendo las tripletas RDF generadas en una base de datos mediante sistemas de gestión
de tripletas RDF de alto rendimiento como Jena TDB (Jena team, 2009) o Sesame (Aduna-Software,
2009), lo cual excede del propósito del presente trabajo.
Por otra parte, la versión desarrollada tiene nivel de prototipo, ya que en ella sólo se traduce un
pequeño porcentaje de los tipos y subtipos DATEX II, por lo que se considera que esta optimización
debería tener en cuenta la traducción de todos los tipos existentes en el modelo y no una parte.
En cualquier caso, esta optimización, así como la implementación de una versión completa de la
pasarela quedaría como una posible extensión del presente trabajo.
Como se comentaba anteriormente, sí se ha considerado interesante la realización de experimentos
para analizar el espacio en memoria necesario para albergar el modelo ontológico en función del
tamaño de los conjuntos de datos, comparándolo además con el espacio necesitado por el modelo
clásico basado en XmlBeans.
Para estos experimentos, se implementó un Test JUnit en el cual un bucle creaba un objeto de tipo
D2LogicalModelDocument (objeto base de XmlBeans para la representación de un documento DATEX II)
del tamaño especificado de dataset para esa iteración. Una vez creado, se transformaba al modelo
ontológico mediante el uso de la pasarela, y posteriormente se añadía el schema OWL al modelo
transformado. Se obtenían por lo tanto tres objetos de test, uno con el modelo clásico mediante
XmlBeans, otro con el modelo basado en ontologías pero conteniendo únicamente los datos, y por
último un modelo ontológico que contenía tanto los datos como las reglas del schema definido9.
Se calcularon las siguientes propiedades de estos tres objetos:
•
Número de bytes utilizados por los datos traducidos (sólo datos).
•
Número de bytes utilizados por el modelo ontológico completo (datos + schema).
•
Número de bytes utilizados por el modelo basado en XmlBeans.
•
Número de tripletas RDF de los datos traducidos (sólo datos).
•
Número de tripletas RDF total (datos + schema).
Para obtener el número de bytes de un objeto se recurrió a la sencilla utilidad Sizeof for Java (Neto,
2008), mientras que el número de tripletas puede ser obtenido fácilmente mediante un método de la
API de Jena.
Se consideraron datasets de hasta 2048 elementos, y se efectuaron un total de doce repeticiones,
eliminando el resultado más alto y más bajo de la serie.
Experimento 1 – Espacio en memoria
El objetivo de este experimento es comprobar que el tamaño ocupado en memoria por los modelos
ontológicos resulta aceptable para el trabajo con los mismos desde aplicaciones habituales.
En esta evaluación de datos se compararon los tamaños en memoria utilizados por cada uno de los
objetos, obteniendo los resultados que pueden verse en la Figura 34.
9
Esta distinción dentro del modelo semántico se planteó de esta forma porque algunas consultas pueden
resolverse sin necesitar tener cargadas en memoria todas las reglas de la ontología, mejorando la eficiencia de la
consulta.
73
Ontología datos
Ontología completa
XmlBeans
Memoria (Kbytes)
1024
512
256
128
1
2
4
8
16
32
64
128
256
512
1024 2048
Datasets
Figura 34: Comparación del tamaño en memoria utilizado por los diferentes tipos de datos
Analizando los valores de la gráfica, los tres presentan una tendencia exponencial muy suave, un
aumento del doble del tamaño del conjunto de datos, no provoca para conjuntos de datos pequeños un
aumento significativo de memoria. Para órdenes de miles de elementos, el tamaño necesario en
memoria empieza a crecer más rápidamente, aunque como ya se ha comentado anteriormente este
hecho no resulta relevante ya que los tamaños reales de conjuntos de datos se encuentran en el orden
del centenar, zona en la que el consumo de memoria permanece muy estable.
En cuanto al tamaño en valores absolutos, es muy similar en el caso de los datos ontológicos y el modelo
clásico mediante XmlBeans, y se encuentra por debajo de 500 Kbyte en la zona de uso práctico. Cuando
se adjunta el modelo ontológico a los datos, la memoria consumida sube aproximadamente 300 Kbyte,
sin embargo, todos estos valores por debajo de 1Mbyte resultan aceptables para trabajar con estos
modelos en memoria al no suponer un aumento significativo respecto a otras implementaciones
clásicas.
Experimento 2 – Tripletas RDF
En el presente experimento se busca estudiar de qué forma aumenta el número de tripletas RDF en
memoria en función del tamaño del conjunto de datos, que no haría sino corroborar el experimento
realizado anteriormente.
74
Ontología datos
Ontología completa
51200
25600
Tripletas RDF
12800
6400
3200
1600
800
400
200
100
50
1
2
4
8
16
32
64
128
256
512
1024 2048
Datasets
Figura 35: Comparación entre las tripletas RDF generadas con y sin el modelo de datos adjunto
Los resultados obtenidos en la Figura 35 resultan bastante esclarecedores, para ambos casos se sigue la
misma tendencia de crecimiento lineal, y puede observarse que, el aumento inicial de las tripletas
debido a las reglas introducidas en el esquema de la ontología es poco a poco minimizado conforme
aumenta el tamaño del conjunto de datos, pudiendo constatarse una posible convergencia cuando el
tamaño del dataset tienda a valores grandes.
Como conclusión que se desprende directamente a partir de estos resultados, la carga en memoria de
las reglas ontológicas no supone un inconveniente en cuanto al espacio ocupado en memoria, si bien
introduce un sobrecoste en memoria no despreciable para números bajos de tripletas RDF.
5.2.2 EVALUACIÓN DE LAS CONSULTAS
Con el objetivo de probar la eficiencia y complejidad de las APIs disponibles para el acceso a datos de
naturaleza ontológica se ha propuesto la evaluación de las consultas de prueba desarrolladas en el
apartado 3.3.
La comparación entre todos estos métodos se efectuará en base a dos parámetros principales:
•
Eficiencia: Tiempo de ejecución total de la consulta. Puede calcularse directamente el tiempo
transcurrido a la función que efectúa la consulta y devuelve los resultados de la misma.
•
Complejidad de desarrollo: Coste de desarrollo de la consulta. Para obtener dicho indicador se
tendrán en cuenta a su vez dos parámetros, una medida de la complejidad del algoritmo utilizado
en cada caso, y otro parámetro que tenga en cuenta la complejidad de aprendizaje y uso de la API
por parte del programador.
El resto del apartado se divide entre la determinación de las medidas de eficiencia para todas las
consultas desarrolladas y el cálculo de la complejidad para cada una de las consultas en base a la
fórmula citada, obteniendo finalmente unas conclusiones a partir de los experimentos y medidas
75
realizadas. Estas conclusiones serán tomadas en conjunto, teniendo en cuenta todos los datos
obtenidos, y el objetivo final será determinar cuál de las aproximaciones resulta más adecuada para
aplicaciones software habituales.
De esta forma, se obtendría una medida más o menos aproximada de lo difícil que es escribir una
consulta en cada API y lo eficiente que es el código generado. El objeto principal será comparar las APIs
semánticas con las APIs clásicas, y por tanto validar el uso de estas nuevas APIs semánticas en
ambientes de ingeniería. Por otra parte, estas medidas ayudarán a obtener una idea global de las
ventajas e inconvenientes de estas APIs, escogiendo la que mejor se adapte a las necesidades futuras de
sistemas basados en Web Semántica.
Complejidad de las consultas
Aunque existen modelos para la estimación de costes en software basados en ontologías (Simperl,
Popov, & Bürger, 2009), en el caso actual no resulta tan relevante esta estimación a priori debido a que
el objetivo es evaluar el esfuerzo real invertido. Para ello, resulta más adecuada (y más sencilla) una
estimación a posteriori, ya que ofrecerá siempre una perspectiva más real del esfuerzo invertido en el
desarrollo del software.
Para obtener una medida de la complejidad de una consulta en una API determinada se tendrá en
cuenta la siguiente fórmula:
Siendo l la API elegida, q la consulta que se está midiendo, IC(l) el índice de complejidad del API elegida
según la Tabla 210, y MET(q) el resultado de una métrica de esfuerzo de desarrollo de la consulta.
API
IC
RDF API
Ontology API
SPARQL
XmlBeans
69
61
82
55
Tabla 2: Índices de complejidad según API de acceso a información ontológica
Existen varias métricas del software que ofrecen una medida para determinar la complejidad del código,
su facilidad de mantenimiento o lo propenso que es a errores. En concreto, dos medidas ampliamente
utilizadas son el simple conteo de líneas de código o la medida de la complejidad ciclomática (McCabe,
1976), que indica el número de caminos independientes de un código fuente.
Los dos modelos anteriores, sin embargo, parecen insuficientes para medir el esfuerzo real de desarrollo
del software. En el caso del conteo de líneas de código, no se tiene en cuenta que ciertas líneas de
código son más difíciles de escribir que otras. Por otra parte, la complejidad ciclomática falla en el
sentido que se pierde información en cuanto a la longitud absoluta del código. De esta forma, un código
fuente muy largo y con pocas condiciones resultará más complejo que otro que sea corto y que presente
más caminos.
Parece por lo tanto más adecuada para el presente proyecto, la aproximación de la sencilla métrica
LOCE (Lines Of Code Equivalence) (Díaz, Métrica y Complejidad del software, 2006). En ella, se tienen en
10
A falta de referencias bibliográficas al respecto, dicha tabla fue elaborada a partir de la experiencia en la
programación de las presentes APIs.
76
cuenta tanto el número de líneas de código como la complejidad de estas líneas, otorgando un
multiplicador mayor según la complejidad ciclomática de cada bloque.
Por lo tanto, la fórmula final utilizada para medir la complejidad de cada consulta será la siguiente:
Mediante la utilidad ToroMetrics 1.0 (Díaz, ToroMetrics v1.0, 2005), pudo medirse el valor LOCE para las
APIs basadas en Java, mientras que en el caso de SPARQL, fue sumada la complejidad del método de
ejecución de la consulta, a las líneas de la consulta propiamente dicha, teniendo en cuenta el
anidamiento de dichas consultas tal como se exige en la definición de la métrica LOCE.
Una vez calculados todos los valores para C(q, l), fue elaborada una tabla que se puede visualizar de
forma gráfica en la Figura 36.
12000
10000
LOCE* IC
8000
6000
4000
2000
0
Q1
Q2
RDF API
Q3
Q4
Ontology API
SPARQL
Q5
Q6
Q7
XmlBeans
Figura 36: Evaluación de la complejidad de las consultas desarrolladas
Teniendo en cuenta el contenido de cada consulta y en base a estos resultados, podrían establecerse
dos grupos principales:
•
Selección de propiedades simples sobre los datos: Correspondería a aquellas consultas que
realizan filtrado sobre los datos desde un punto de vista clásico, es decir, obteniendo las instancias
que responden a unos requisitos, y extrayendo de ellas las propiedades necesarias. En estos casos,
las cuatro implementaciones requieren aproximadamente el mismo esfuerzo, aunque SPARQL y
Ontology API gozan en general de cierta ventaja sobre las otras. Una posible razón para ello sería
que SPARQL, para obtener el valor de un dato, le basta con especificar en la cláusula SELECT una
referencia al recurso objeto, resultado de aplicar una propiedad a una instancia. Por su parte,
Ontology API dispone de funciones de acceso rápido a propiedades de recursos, lo que facilita la
programación en este sentido. Las consultas Q1, Q4 y Q6 pertenecerían a esta categoría.
•
Consultas que se aprovechan de semántica para su ejecución: En este tipo de consultas se aplican
ciertas reglas semánticas generales (herencia entre clases, satisfacción de enunciados lógicos) para
la obtención de los resultados. Estas reglas han sido añadidas al modelo semántico, y para
emularlas en el modelo clásico mediante XmlBeans, es preciso categorizar mediante condiciones los
objetos que responden a una característica. Por ejemplo, en el modelo original de DATEX II, no se
77
considera si un objeto implicado en un accidente es o no peligroso, por lo que se ha debido de
efectuar una comprobación para cada tipo que responda a dicha característica, alargando el código
fuente resultante y por lo tanto el esfuerzo requerido para su implementación. Debido a ello, en las
gráficas aparece representado un esfuerzo sustancialmente mayor en XmlBeans que en el resto de
implementaciones. Q2, Q3, Q5 y Q7 pertenecerían a esta categoría, aunque Q3 requiere un
esfuerzo bajo (similar a SPARQL), debido a la facilidad de ordenación por fecha frente a Ontology
API y RDF API, donde se requirieron más líneas de código para ello.
En cuanto a la comparación entre las APIs semánticas, es posible observar que las tres requieren una
complejidad total similar, aunque en general RDF API es más costosa que Ontology API, y ésta última
más costosa que SPARQL, que a pesar de su alto nivel de IC, consigue un valor de C(q, l) muy pequeño
debido al bajo valor LOCE conseguido en las consultas.
Eficiencia de las consultas
Para todos los experimentos se han utilizado conjuntos de datos de hasta 1024 elementos, midiendo
mediante tests JUnit el tiempo de ejecución de cada consulta en el transcurso de doce repeticiones, de
las cuales se ha eliminado el mejor y el peor tiempo.
Se ha considerado como parte del tiempo de ejecución, además del propio tiempo de ejecución de la
consulta, el tiempo necesitado para la llamada al método en Java, así como la representación por
pantalla de los resultados. Aunque estas inclusiones hacen que no se obtenga una medida totalmente
real en términos absolutos de la eficiencia de la consulta, sí que obtiene una idea fiel del tiempo de
desempeño en una aplicación real, donde son habituales las interacciones con el usuario en forma de
entradas y salidas .
Experimento 3 – Eficiencia de la consulta Q1
En este caso se efectúa una selección sobre los datos buscando un recurso de tipo escenario mediante
su URI, obteniendo un único elemento del total. Para minimizar posibles ventajas de ejecución de las
API11 se ha elegido siempre el elemento medio de la serie.
En la Figura 37 se muestran los resultados gráficos a partir de los datos obtenidos en los test
desarrollados.
11
Ciertas implementaciones pueden organizar de una forma especial los elementos en memoria, poniendo por
ejemplo el primer elemento insertado en primera o última posición, lo cual podría introducir un sesgo en los
resultados obtenidos.
78
RDF API
Ontology API
SPARQL
XmlBeans
102,4
51,2
Tiempos (ms)
25,6
12,8
6,4
3,2
1,6
0,8
0,4
0,2
1
2
4
8
16
32
64
128
256
512
1024
datasets
Figura 37: Eficiencia de ejecución para la consulta Q1
El primer hecho que llama la atención es que XmlBeans sigue una subida suave que acaba en una
tendencia lineal con el número de elementos, a partir del test de 32, efecto que no sufren las otras
implementaciones, que son sensiblemente mejores y que no acusan el incremento del tamaño del
conjunto de datos.
Otro dato que se desprende del gráfico es que Ontology API y RDF API tienen un desempeño muy
similar, mientras que SPARQL necesita unos pocos milisegundos más para llevar a cabo sus consultas,
aunque prácticamente no sería relevante debido a su tendencia constante.
En este caso, en el que al igual que en Q1 se realiza una selección sobre los datos, aunque en este caso
se hace una búsqueda a segundo nivel (situaciones dentro de escenarios), buscando por el valor de la
propiedad situationRecordCreationReference y no por la URI directa del recurso. El identificador es, al
igual que en el caso anterior, el valor mediana de la serie. Además, se obtiene información más
detallada sobre el recurso, incluyendo dos atributos opcionales que se dan sólo en los objetos de tipo
accidente.
La Figura 38 muestra de forma gráfica el resultado de las pruebas realizadas.
79
RDF API
Ontology API
SPARQL
XmlBeans
102,4
51,2
25,6
Tiempos (ms)
12,8
6,4
3,2
1,6
0,8
0,4
0,2
1
2
4
8
16
32
64
128
256
512
1024
datasets
Figura 38: Eficiencia de ejecución para la consulta Q2
Las tendencias seguidas son muy similares a las de Q1, si bien en este caso el tiempo de ejecución de
todas las consultas es aproximadamente el doble (probablemente por el aumento de información
requerido en la consulta).
Una vez más, XmlBeans se muestra más lento que las implementaciones en el resto de APIs, cuyos
tiempos se mantienen en tiempos constantes en base al número de elementos.
Para llevar a cabo esta consulta, se determina una hora de corte restando 6 horas a la hora actual. Ya
que los datos de los dataset contienen como fecha entre una hora y doce de la fecha actual, esta
consulta devolverá aproximadamente el 50% de los datos. Además, es necesaria una ordenación de los
datos, lo cual consumirá tiempo en todos los casos. Esta ordenación se efectúa de forma nativa en
SPARQL, mientras que en el resto de implementaciones se utiliza el método sort de la clase Collections,
que utiliza una variante del algoritmo mergesort, que asegura un tiempo de ordenación de n * log(n).
En la Figura 39 pueden observarse los resultados obtenidos, muy similares para las cuatro
implementaciones, de forma gráfica.
80
RDF API
Ontology API
SPARQL
XmlBeans
1024
512
256
128
tiempos (ms)
64
32
16
8
4
2
1
0,5
0,25
1
2
4
8
16
32
64
128
256
512
1024
datasets
Figura 39: Eficiencia de la ejecución para la consulta Q3
Las cuatro implementaciones siguen en este caso una tendencia lineal muy parecida, aunque XmlBeans
y más aun SPARQL, consiguen una ligera ventaja respecto a las otras dos APIs.
En este caso se realiza, al igual que en el caso anterior, un filtro que obtiene aproximadamente un 50%
de resultados del total, al seleccionar sólo accidentes, mostrando además su tipo original.
La Figura 40 muestra de forma gráfica los resultados del testeo.
81
Tiempos (ms)
RDF API
Ontology API
SPARQL
XmlBeans
819,2
409,6
204,8
102,4
51,2
25,6
12,8
6,4
3,2
1,6
0,8
0,4
0,2
0,1
0,05
1
2
4
8
16
32
64
128
256
512
1024
datasets
En este caso, en el que se realizaba inferencia directa sobre el tipo de las clases, XmlBeans se muestra
como la API más rápida en general, aunque el resto siguen la misma tendencia lineal y se encuentran en
el mismo orden de magnitud.
La consulta Q5 realiza una selección muy restrictiva sobre los datos, quedándose únicamente con
aquellos accidentes que tengan un objeto implicado y que además ese objeto sea peligroso para la
circulación.
En la Figura 41 pueden observarse gráficamente los resultados de los test realizados.
82
RDF API
Ontology API
SPARQL
XmlBeans
204,8
102,4
51,2
Tiempos (ms)
25,6
12,8
6,4
3,2
1,6
0,8
0,4
0,2
0,1
1
2
4
8
16
32
64
128
256
512
1024
datasets
Estos resultados son muy similares a los registrados en Q4, aunque la diferencia en cuanto a rapidez
entre XmlBeans y el resto de APIs es más notable para conjuntos más pequeños de datos. Sin embargo,
la tendencia lineal del resto de APIs es menos pronunciada que en XmlBeans, por lo que para tamaños
de dataset grandes el tiempo requerido llega a niveles similares. SPARQL comienza otra vez con valores
visiblemente peores que el resto de implementaciones, aunque conforme aumenta el tamaño del
conjunto de datos, mantiene una pendiente de subida más baja que el resto.
Para este caso, se elije un valor aleatorio intermedio (en este caso 500), valor que deberá estar
contenido en los tramos de las situaciones que satisfagan la consulta. Para esta situación, se obtiene la
información relevante respecto a la localización. Un porcentaje relativamente bajo (10%
aproximadamente) de las situaciones satisfacen esta condición.
En la Figura 42 se obtiene una representación gráfica de los resultados obtenidos.
83
Tiempos (ms)
RDF API
Ontology API
SPARQL
XmlBeans
6553,6
3276,8
1638,4
819,2
409,6
204,8
102,4
51,2
25,6
12,8
6,4
3,2
1,6
0,8
0,4
0,2
1
2
4
8
16
32
64
128
256
512
1024
datasets
Como en el caso anterior, XmlBeans consigue la mayor eficiencia de las APIs, aunque se muestra menos
escalable que RDF API y Ontology API para conjuntos de datos grandes. SPARQL muestra una tendencia
ligeramente exponencial, por lo que, aunque para conjuntos de datos pequeños su actuación es
aceptable, a partir de 512 elementos el tiempo de ejecución se dispara.
Para la resolución de esta costosa consulta es necesario cruzar dos listados independientes de
situaciones para obtener aquellas parejas que comparten un código Alert-C intermedio. Su resolución,
por lo tanto, implica un orden cuadrático según el número de elementos, además de que la probabilidad
de existencia de parejas aumenta con el número de elementos del dataset, debiendo escribir durante
más tiempo por pantalla.
84
Tiempos (ms)
RDF API
Ontology API
SPARQL
XmlBeans
52428,8
26214,4
13107,2
6553,6
3276,8
1638,4
819,2
409,6
204,8
102,4
51,2
25,6
12,8
6,4
3,2
1,6
0,8
0,4
0,2
1
2
4
8
16
32
64
128
256
512
1024
datasets
Tal como se esperaba, las cuatro implementaciones siguen una tendencia cuadrática con el número de
elementos, si bien XmlBeans presenta la peor actuación a partir de 16 elementos. En el funcionamiento
interno de los algoritmos, XmlBeans necesita obtener todas las posibles parejas de localizaciones y luego
discriminar aquellas que cumplen la condición. Las APIs semánticas permiten actuar de forma distinta, al
obtener, a partir del primer listado de localizaciones del primer punto, sólo aquellas localizaciones del
segundo punto que cumplan la condición, recogiendo posteriormente las situaciones a las cuales
pertenece esta segunda localización. Las tres APIs semánticas tienen un desempeño similar, aunque en
este caso RDF API funciona ligeramente mejor que el resto.
Interpretación de resultados
Combinando los resultados obtenidos tanto en complejidad como eficiencia de las consultas, es posible
extraer algunas conclusiones determinantes sobre el uso de estas APIs.
En primer lugar, se ha mostrado que las APIs semánticas en conjunto son una solución tan válida como
XmlBeans para trabajar con la información proveniente de DATEX II. En todos los casos, la medida de la
eficiencia para llevar a cabo las consultas ha ofrecido órdenes de magnitud muy similares, resultando
incluso mejores que las aproximaciones habituales en aquellos casos en los que el uso de estrategias
basadas en la semántica facilita la selección (Q1, Q2) o el cruzado de información (Q7).
El ejemplo más claro es la búsqueda de un recurso con un determinado URI. En un ambiente semántico,
esto supone una pregunta a la base de conocimiento de aquella instancia que responda a esta URI, lo
cual tiene un coste muy bajo en comparación a la estrategia clásica: la búsqueda lineal en la que se
compara que un atributo de una clase (un identificador en este caso) es igual al parámetro dado.
Se constata además que en aquellos casos que XmlBeans ha conseguido una ventaja en cuanto a
eficiencia, lo ha hecho mediante el alargamiento del código fuente. Por ejemplo, en Q4 y en Q5 se ha
85
obtenido un rendimiento ligeramente mejor (aunque también de tendencia lineal) a costa de un
incremento del esfuerzo en el código fuente, en especial en el caso de Q5, que cuadriplica el esfuerzo de
las APIs semánticas. En estos casos, el modelo semántico obtiene directamente instancias de un tipo
determinado (Accidentes) utilizando inferencia lógica (mediante el simple axioma un Accidente es una
Situación de tráfico). Para llevar a cabo esta tarea, XmlBeans necesita recorrer todos los registros y
averiguar su tipo, y en el caso que sean del tipo deseado para acceder a las características propias de
cada tipo necesita realizar varios cast y evaluación de condiciones, lo cual supone un esfuerzo de
programación importante.
Un caso especial se observa en Q3, en el que XmlBeans ha obtenido una eficiencia mejor sin
incrementar el esfuerzo de realización de código. Esto es porque, para XmlBeans sólo se necesitó una
línea de código para implementar la función de comparación entre dos registros, mientras que en
Ontology API y RDF API se necesitó un bloque complejo para ello. Sin embargo, incluso en este caso
SPARQL utilizó la cláusula ORDER para la ordenación, consiguiendo un menor esfuerzo final. En cualquier
caso, se detecta aquí una carencia en cuanto a funciones de ordenación para las APIs semánticas
programáticas.
Ya dentro de las APIs semánticas, se observa en general que SPARQL requiere de un menor esfuerzo de
programación que el resto sin comprometer la eficiencia. En cuanto a este parámetro, aunque parece
necesitar un mayor tiempo de base para la ejecución de consultas, a la larga se muestra tan bueno o
mejor que el resto de APIs.
Por último, RDF API y Ontology API tienen desempeños similares, siendo Ontology API ligeramente
mejor en cuanto al esfuerzo necesario para su programación, siendo más comprensible y sencillo de
implementar, por lo que se recomienda su uso ante RDF API.
Conclusiones finales
Tal y como se había planteado en los objetivos del apartado, se ha demostrado que la explotación de
modelos semánticos estaría plenamente justificada en dominios prácticos de ingeniería, tanto en
relación a la complejidad del código resultante como a la eficiencia del código producido. Se constituye
así el modelo semántico como una alternativa plenamente válida a otros modelos clásicos de
ingeniería.
Dentro de las APIs semánticas, tanto SPARQL como Ontology API ofrecen rendimientos aceptables con
esfuerzos pequeños, aunque en este último aspecto SPARQL se considera mejor ya que ofrece una
visión más sencilla sobre los modelos semánticos y provee de herramientas de filtrado y ordenación que
de otra forma han de implementarse de forma programática.
SPARQL ofrece además una ventaja adicional que no ha sido considerada, pero que puede resultar de
gran utilidad: permite la consulta nativa a más de una fuente mediante cláusulas FROM, lo cual facilita la
integración entre distintas fuentes. Para llevar a cabo este cometido en un ambiente de programación
sería necesario el establecimiento de una llamada a la función de consulta, necesitando integrar de
forma manual los listados obtenidos en cada consulta por separado, incrementando así el coste
computacional y el esfuerzo de programación.
En cuanto a la mantenibilidad del código fuente, aunque Ontology API tendría la importante ventaja de
soportar técnicas de refactorización12 de código, SPARQL compensa esta deficiencia al no requerir
realmente estas recompilaciones de código al efectuar mantenimiento. En el caso de necesidad de
12
Mediante esta técnica, presente en muchos entornos de programación, un cambio en el nombre de una clase de
la ontología inmediatamente se vería propagado a todas las clases que lo utilicen.
86
cambios es posible modificar únicamente los ficheros donde se encuentre implementada la consulta sin
modificar el código destinado a ejecutarla, permitiendo así además cambios en caliente, muy útiles en
plataformas 24/7.
Debido a todas estas características, finalmente se puede recomendar el uso de SPARQL sobre el resto
de APIs semánticas, aunque Ontology API deberá ser tenido en cuenta para la implementación de
consultas en ciertos casos particulares.
5.3
VISUALIZACIÓN DE INFORMACIÓN
Desde un punto de vista funcional, se ha propuesto comprobar las facilidades para la visualización de
información del modelo planteado.
Para ello, y mediante la utilidad online Tabulator (Berners-Lee & Dharanaj, Tabulator 0.8, 2006), se ha
accedido a una fuente de datos RDF generada directamente por la pasarela DATEX II – DATEX II
Semántico.
Para la definición de datos se utilizó una consulta SPARQL en la que se obtenía información relevante
sobre una localización, incluyendo información geográfica según la ontología Basic Geo (W3C - Semantic
Web Interest Group, 2009), definida en la información semántica obtenida por la pasarela a partir de las
coordenadas descritas en la sección TPEG de un mensaje DATEX II.
Figura 44: Consulta SPARQL para la extracción de resultados representables sobre Tabulator
Tabulator devuelve un conjunto de tuplas representadas de forma tabular con la información resultado
de la ejecución de la consulta.
Figura 45: Representación tabular del resultado de una consulta SPARQL sobre Tabulator
87
Además, como se ha incluido información geográfica (latitud, longitud), Tabulator muestra una vista de
forma nativa con la información representada en un mapa.
Figura 46: Representación gráfica sobre un mapa del resultado de una consulta SPARQL sobre Tabulator
Con un esfuerzo muy pequeño (implementación de una sencilla consulta SPARQL) se ha conseguido una
representación avanzada de la información contenida en la ontología, con lo que se ponen de manifiesto
las facilidades que ofrece el modelo semántico implementado para la visualización de información.
5.4
DISCRIMINACIÓN DE MENSAJES EN BASE A PERFILES
El objetivo directo de la plataforma de publicación construida en el capítulo 4 es la clasificación
automática de mensajes (toma de decisiones) en base a las preferencias de cada usuario. Estos perfiles,
definidos en el apartado 4.2, serán utilizados para evaluar a modo de ejemplo una batería de mensajes,
determinando si resultarían aceptables o no para cada perfil y en qué grado.
Batería de mensajes
Las características de los mensajes que servirán como entrada para la evaluación de su importancia son
los definidos en la Tabla 3. Se utiliza un código de estrellas para indicar la prioridad13.
Distancia
usuario
Diferencia
tiempo
Prioridad
M1
M2
M3
M4
M5
M6
M7
M8
M9
1 km
1 km
1 km
20 km
20 km
60 km
60 km
100 km
100 km
1 min
1 min
150 min
5 min
30 min
30 min
60 min
10 min
360 min
*****
*
****
*****
***
****
**
*****
*
Tabla 3: Cuadro resumen de las características de la batería de mensajes elegida
Considerando iguales las funciones de pertenencia para todos los perfiles14, se obtendrían los valores
para los mensajes que aparecen en las siguientes tablas (los valores representados por guiones
pertenecerían a puntos no evaluables para la etiqueta, por lo que su valor sería 0).
13
***** URGENTE; ****  PRIOTARIO; ***  NORMAL; ** AVISO; *  INFORMACIÓN
Es preciso recordar que estas funciones de pertenencia podrían ser personalizadas por los usuarios en caso de no
querer utilizar los valores por defecto definidos para los conceptos de usuario.
14
88
PRÓXIMO
CERCANO
DISTANTE
LEJANO
M1
1.0
-
M3
1.0
-
M2
1.0
-
M4
0.37
0.63
-
M5
0.37
0.63
-
M6
0.03
0.97
-
M8
1.0
M9
1.0
M8
0.93
0.05
-
M9
0.01
0.99
M7
0.03
0.97
-
Tabla 4: Valores obtenidos para la variable lingüística distancia
NUEVO
RECIENTE
ANTIGUO
M1
1.0
-
M2
1.0
-
M3
0.83
0.12
M4
0.97
0.02
-
M5
0.76
0.16
-
M6
0.76
0.16
-
M7
0.51
0.33
-
Tabla 5: Valores obtenidos para la variable lingüística validez
Clasificación
Según estos valores y tomando en cuenta las reglas definidas para cada uno de los perfiles especificados
en el apartado 4.2.3, se ha efectuado una clasificación de mensajes según las reglas a aplicar, que puede
observarse en la Tabla 6.
Regla
Mensajes
R0
M1, M2, M3, M4, M5, M6, M7, M8, M9
R_O1
R_O2
R_O3
R_O4
R_O5
R0
M2
M1, M4, M5, M6, M7, M8
M3
M9
-
R_A1
R0
M9
M1, M2, M3, M4, M5, M6, M7, M8
R_P1
R_P2
R_P3
R_P4
R_P5
R0
M1, M4, M8
M2, M3
M5, M6, M7
M9
R_R1
R_R2
R_R3
R_R4
R0
M1, M3
M4, M5
M2
M6, M7, M8
M9
Semántico
Operador
Analista
Policía
RDS-TMC
Tabla 6: Aplicación de reglas a mensajes para perfiles de tráfico
Una vez aplicadas las reglas se obtiene una clasificación de la importancia de cada mensaje para cada
uno de los perfiles. Esta clasificación se detalla en la Tabla 7.
89
M1
NORMAL
M2
NORMAL
Operador
EXTREMADAMENTE
IMPORTANTE
MUY IMPORTANTE
M3
NORMAL
MUY IMPORTANTE
M4
NORMAL
M5
NORMAL
M6
NORMAL
M7
NORMAL
M8
NORMAL
M9
NORMAL
Semántico
EXTREMADAMENTE
IMPORTANTE
EXTREMADAMENTE
IMPORTANTE
EXTREMADAMENTE
IMPORTANTE
EXTREMADAMENTE
IMPORTANTE
EXTREMADAMENTE
IMPORTANTE
POCO IMPORTANTE
RDS-TMC
EXTREMADAMENTE
IMPORTANTE
IMPORTANTE
EXTREMADAMENTE
IMPORTANTE
NORMAL
NORMAL
Policía
EXTREMADAMENTE
IMPORTANTE
MUY IMPORTANTE
NORMAL
MUY IMPORTANTE
NORMAL
EXTREMADAMENTE
IMPORTANTE
MUY IMPORTANTE
NORMAL
MUY IMPORTANTE
MUY IMPORTANTE
NORMAL
MUY IMPORTANTE
IMPORTANTE
NORMAL
MUY IMPORTANTE
IMPORTANTE
Analista
NORMAL
IMPORTANTE
EXTREMADAMENTE
IMPORTANTE
NORMAL
IMPORTANTE
NORMAL
Tabla 7: Determinación de importancia de mensajes para los perfiles de información de tráfico
Teniendo además en cuenta la cota de importancia, el listado final de mensajes para cada perfil que
sería presentado al usuario sería el siguiente:
Semántico
Operador
Analista
Policía
RDS-TMC
Ordenación
M1, M2, M3, M4, M5, M6, M7, M8, M9
M1, M4, M5, M6, M7, M8, M2, M3, M9
M9
M1, M4, M8, M2, M3, M5, M6, M7
M1, M3, M4, M5, M2, M6, M7, M8
Descartados
M1, M2, M3, M4, M5, M6, M7, M8
M9
M9
Tabla 8: Listado ordenado de mensajes por perfil
Aunque coinciden en gran parte los listados (los mensajes M1 y M4 aparecen en las primeras posiciones,
mientras que el mensaje M9 en las últimas), cada perfil adecua la ordenación a sus preferencias.
Además, el modelo es lo suficientemente general para aceptar casos particulares como el perfil Analista,
consiguiendo quedarse sólo aquellos eventos lo suficientemente antiguos para resultar relevantes para
su análisis.
Faltaría únicamente una fase de transformación, para la cual el componente Conversion determinaría el
formato adecuado de representación para cada perfil, y se encargaría de trabajar con servicios
adicionales de transformación para obtener la información traducida en base a los requerimientos del
cliente.
Conclusiones
Se ha comprobado la validez del modelo propuesto para la representación de características basado en
perfiles. Con una simple especificación de reglas expresables en lenguaje natural (definición que podría
obtenerse después de una simple toma de requisitos) se ha conseguido representar preferencias muy
dispares, lo cual pone de relevancia la flexibilidad del modelo.
Por otra parte, aunque no ha sido necesaria su utilización en el experimento planteado, es posible y
podría ser adecuado en muchos casos la definición de funciones de pertenencia personalizadas para
cada usuario. Por ejemplo, de esta forma un determinado perfil podría tener una consideración distinta
del concepto “cercano”, lo cual sería modelado mediante la definición de funciones de pertenencia
distintas adecuadas para los intereses del perfil. Esta característica adicional dotaría de una mayor
elasticidad al modelo, a costa de una mayor complejidad que en todo caso sería opcional.
90
6. Conclusiones
6
CONCLUSIONES
En base a los objetivos que se han planteado al principio de la memoria se plantean las siguientes
conclusiones:
•
La Web Semántica representa la unión de diferentes conceptos y teorías para llevar a cabo una
evolución de la Web actual. En lo que a la investigación se refiere, desde que Tim Berners-Lee
sentara las bases de la Web Semántica, han aparecido multitud de aproximaciones, extensiones y
algoritmos, que conjuntamente están preparando el salto de la Web Semántica a la Web del futuro.
El estado del arte del presente trabajo se ha centro en una revisión sobre los artículos e
investigaciones aparecidos en los últimos años en esta área, destacando las distintas concepciones
existentes dentro de la Web Semántica y los caminos que podría tomar. En el dominio de los ITS, la
Web Semántica se presenta como una herramienta útil para la representación del amplio
conocimiento de los modelos asociados al tráfico, así como para la integración de servicios que se
faciliten la gestión de la información, tanto desde el punto de vista de un operador como para los
usuarios finales.
•
Para la evolución de DATEX II a un modelo semántico se ha tomado como base una ontología
desarrollada en un trabajo previo (Canós Gandía, 2003). Se ha llevado a cabo una importante
actualización de la misma adaptándola en primer lugar a la última versión del propio modelo base
DATEX II, corrigiendo además algunos errores encontrados y mejorando la definición de jerarquías
de términos y propiedades. Una vez construida la ontología se ha desarrollado un prototipo de
pasarela que transforma la información basada en el modelo DATEX II a otro modelo basado en
ontologías. Se ha validado el modelo semántico como una alternativa al modelo clásico,
observando tiempos de ejecución similares para las consultas efectuadas sobre ambos modelos, y
un esfuerzo de desarrollo menor y por lo tanto menos costoso en los modelos basados en
semántica.
•
Después de una evaluación de varias APIs semánticas de consulta (basadas en Jena), se ha
determinado SPARQL como la que más facilita el desarrollo de consultas, siendo además muy
escalable en sus tiempos de ejecución para conjuntos de datos de tamaño medio o grande. Ofrece
además otras ventajas como la integración nativa de fuentes de información semántica, o la
ordenación y selección de campos, características que presentan una complejidad importante en el
resto de aproximaciones programáticas.
•
La lógica difusa ha resultado de gran ayuda para la representación de conceptos reales,
permitiendo el modelado de categorías continuas la inclusión de reglas basadas en enunciados
aproximados. Este tipo de reglas funciona especialmente bien en el caso del modelado de
preferencias de usuarios, debido a su cercanía con el lenguaje natural.
•
Se ha diseñado una arquitectura general para la publicación de información semántica basada en
perfiles. El sistema se basa en un conjunto de componentes funcionales que se encargan de los
procesos asociados a la extracción, gestión y transformación de la información semántica. Son
definidas además una serie de ontologías mediante las cuales se definen los parámetros asociados a
un usuario, incluyendo la definición de las preferencias de usuario aplicables a la información que se
extraerá de los repositorios semánticos. El resultado es un sistema flexible desde el punto de vista
del usuario final, que obtiene una vista totalmente personalizada de la información semántica. Al
tener en cuenta además las características del contexto del usuario en tiempo real, este sistema
podría calificarse además como adaptativo.
•
Se ha aplicado la arquitectura de publicación de información al dominio del tráfico, detallando
cinco perfiles de prueba, modelando sus preferencias y las reglas que las acaban definiendo.
91
Después de la clasificación de un conjunto de mensajes de prueba, se ha observado que el sistema
adecua la ordenación final de mensajes en base a las preferencias definidas por cada perfil. La
complejidad del sistema es muy pequeña, por lo que se considera una posibilidad interesante para
este tipo de sistemas con usuarios predefinidos muy heterogéneos.
•
El factor multimodal ha sido tenido en cuenta en el desarrollo de la arquitectura de publicación,
considerando un componente de traducción de información que permitiría la presentación de la
información semántica en formatos diferentes en base a las preferencias del usuario. En este
apartado será necesario tener en cuenta también la calidad del servicio ofrecido, ya que estos
servicios de traducción normalmente serán ofrecidos por terceros, y además será común el
encadenamiento de transformaciones utilizando, propagando la pérdida de información en cada
paso.
En base a las anteriores conclusiones, puede decirse por lo tanto, que el objetivo principal, que daba
nombre al presente proyecto, se ha conseguido con éxito y que los trabajos desarrollados podrán ser
utilizados como una base sólida para posibles investigaciones futuras, aspecto fundamental que se
había planteado en el presente trabajo.
Una vez llegado a este punto y visto que se han satisfecho en mayor o menor medida los objetivos
planteados, es posible emprender la respuesta de las preguntas principales de investigación que se
planteaban al principio del trabajo:
¿Es DATEX II una base adecuada para la creación de una ontología que represente el conocimiento
existente en el dominio de tráfico?
Sí, DATEX II es el resultado de años de trabajo llevados a cabo por una comunidad expertos provenientes
de distintos países, que ponen en común ideas y puntos de vista bien diferenciados, lo cual es realmente
la base para la investigación en cualquier ámbito. El producto final reúne por lo tanto, todas las
características para ser considerado un modelo válido de representación del conocimiento existente en
el dominio del tráfico en la actualidad.
¿Qué modificaciones es necesario realizar en el modelo para adaptarlo a este cometido?
DATEX II ha sido pensado de una forma eminentemente práctica, con lo que algunas simplificaciones
han llevado a incoherencias en un plano teórico, que ha sido necesario solventar. Por ejemplo, DATEX II
limita la profundidad en las jerarquías, mientras que la semántica esencialmente se basa en ello para la
definición de taxonomías precisas, que correspondería al lenguaje de la ciencia en una gran cantidad de
ámbitos científicos. Otros parámetros, en especial aquellos asociados a categorías, son definidos de
forma abrupta. En el transcurso del trabajo se han señalado la posibilidad de introducción de modelos
difusos en este sentido para aproximar a la realidad el modelo definido.
El paso a una infraestructura basada en el conocimiento aporta sin duda complejidad al modelo general.
¿Qué mejoras aporta el uso de un modelo semántico sobre un modelo clásico?
En cuanto a eficiencia en términos de ejecución, parámetro importante en algunos sistemas no se
observa prácticamente ninguna mejora salvo en casos particulares. Sí se observa una mayor facilidad de
implementación, lo cual redunda en un esfuerzo de desarrollo más pequeño (y por tanto un menor
coste), mejorando así además la mantenibilidad del código.
¿Podrá ser el modelo resultante interoperable entre los sistemas ya existentes?
La respuesta en este caso sería depende. Para el escenario de uso del presente trabajo, en el cual la
información albergada en la base de conocimiento se obtiene a través de una pasarela de traducción,
92
6. Conclusiones
sería posible hacer uso de un servicio de transformación más, que se encargara de volver a traducir el
modelo semántico al modelo DATEX II. Este método tendría una pérdida mínima de información y sería
totalmente interoperable con clientes DATEX II. Sin embargo, si se trabaja con aplicaciones que
permitan la interacción con la información semántica de forma nativa, existirá siempre una pérdida de
información más o menos notable, ya que algunos parámetros y definiciones que es fácil expresar en el
modelo semántico, podrían no ser representables mediante el modelo MDA de DATEX II.
¿Siguen ofreciendo las ontologías una representación del conocimiento adecuada?
Sí, aunque existen una gran cantidad de aproximaciones, las ontologías junto a la Web Semántica es uno
de los métodos más activos actualmente en lo que a investigación se refiere, especialmente en sistemas
orientados a servicios.
¿Qué formatos y herramientas de representación son los más apropiados en la actualidad?
En cuanto a los formatos, RDF y OWL se han convertido en estándares de facto, el primero para el
almacenamiento de contenidos y el segundo como metalenguaje de definición de conceptos,
propiedades y restricciones entre otros elementos. Para la representación de ontologías no existe una
herramienta definitiva, aunque parece que el uso de Protégé se encuentra bastante extendido en la
actualidad.
¿Es posible asegurar un marco de referencia que permita la explotación de la información de forma
semántica en forma de aplicaciones inteligentes?
Actualmente existe bastante trabajo pendiente al respecto. En el presente proyecto se ha definido una
arquitectura para la publicación de información semántica basada en perfiles, que podría ofrecer una
idea básica de sistemas futuros de explotación de información en la Web Semántica.
En base a los resultados obtenidos, ¿es posible la generalización de los experimentos y resultados
obtenidos para la extracción de conclusiones aplicables a otros dominios?
Para los experimentos relacionados con parámetros técnicos asociados a consultas, es de esperar que el
comportamiento de los modelos clásicos y semánticos se repita a través de todos los dominios, aunque
parece difícil definir un conjunto genérico de pruebas (benchmarking) para medir el desempeño en
general, debido a la disparidad de criterios y requisitos en cada área de aplicación.
En cuanto a la plataforma de publicación de información semántica basada en perfiles, ha sido diseñada
desde un punto de vista lo más general posible, por lo que en este caso sí sería muy sencillo adaptar el
trabajo realizado para la extensión a otros dominios distintos del tráfico.
93
7. Trabajo futuro
7
TRABAJO FUTURO
En el transcurso del presente trabajo, se han ido esbozando algunos problemas complejos que podrían
ser ampliados en futuras investigaciones. Se han relacionado estos temas con líneas abiertas de estudio,
que tienen en la actualidad una actividad importante en el ámbito investigador:
•
Descripción lógica de las ontologías: En el presente trabajo se ha determinado mediante
herramientas destinadas a ello, la expresividad de la ontología DATEX II, que en notación DL sería
, que utiliza propiedades intermedias entre OWL-DL y OWL-Lite. Una vía de trabajo
interesante podría ser, determinar de forma exhaustiva todas las propiedades lógicas que se
derivan y analizar si sería interesante realizar cambios en la ontología, bien para mejorar la
complejidad teórica obtenida reduciendo la expresividad, bien para mejorar la expresividad aunque
la complejidad teórica se vea perjudicada. Por otra parte, la aparición de perfiles en OWL 2 también
ofrece un nuevo conjunto de posibilidades que convendría valorar. En especial, los perfiles OWL 2
EL y OWL 2 RL proporcionan un conjunto de características que podría ser interesante aprovechar
para el desarrollo de la ontología. Sin embargo, al ser OWL 2 una tecnología relativamente
novedosa, el conjunto de técnicas de que ella derivan, harían necesario un estudio en profundidad.
•
Gestión avanzada de reglas: El modelo basado en reglas difusas propuesto para la clasificación de
mensajes en base a las preferencias de usuarios, aunque satisface funcionalmente la tarea para la
que está diseñado, es un sistema básico que convendría reforzar y formalizar. En (Sáez Esteve,
2007) se efectuó un análisis del estado del arte en lo que se refiere a sistemas expertos basados en
reglas, construyendo un modelo de agentes basado en reglas para la gestión del tráfico. Este trabajo
podría ser tomado como referencia para la mejora del sistema de gestión de reglas, teniendo en
cuenta de forma adicional el soporte de información imprecisa como requisito.
•
Resolución de empates en la clasificación de mensajes: Uno de los aspectos concretos en los que
se podría trabajar sería en el tratamiento de empates en la clasificación de mensajes. El modelo
planteado organiza los mensajes en función de la Importancia relativa para cada usuario. Sin
embargo, dentro de una misma categoría no existe un criterio para la resolución de empates.
Aunque este problema podría ser abordado mediante la inclusión de nuevas categorías (haciendo
más pequeña la granularidad de la variable lingüística), esto aportaría complejidad al modelo,
solucionando el problema sólo en parte. Otra posible solución más sólida sería asignar un grado
difuso de verdad a las afirmaciones15. La dificultad de este método estriba en encontrar un método
para la agregación de estas variables, campo en el que se ha estado trabajando intensamente
durante los últimos años, y en el que sería interesante profundizar.
•
Benchmarking en la plataforma de publicación de información de tráfico basada en perfiles: La
idea es aplicar algunos benchmarks comunes en el campo de las ontologías (ontología Books, Wines
o Pizza) a la plataforma genérica que se ha propuesto, proponiendo perfiles para la publicación de
información. Estas pruebas podrían ayudar a validar el ámbito generalista con el que se ha
planteado esta plataforma y ayudar a su aplicación a otros dominios.
•
Calidad de servicio de traducción: Aunque se determina una medida de la calidad de un servicio de
traducción en el transcurso del trabajo, sería necesario establecer un modelo sólido que tuviera en
cuenta métricas avanzadas asociadas a la calidad del servicio ofrecido. De esta forma podría
obtenerse una medida de lo “adecuado” que es un servicio, medida que ayudaría en la elección del
servicio que mejor se ajuste para resolver el problema planteado.
15
De esta forma, un evento PRÓXIMO (1.0) y NUEVO (1.0) sería EXTREMADAMENTE IMPORTANTE (1.0), pero un
evento PRÓXIMO (0.7) y NUEVO (0.9) podría denotarse como un evento EXTREMADAMENTE IMPORTANTE (0.8) y
MUY IMPORTANTE (0.2).
95
•
Descubrimiento de servicios de traducción: Una característica deseable del sistema sería que
permitiese la incorporación dinámica de nuevos servicios de traducción. Por ejemplo, si se descubre
la presencia de un servicio público que se encarga de la traducción de información dada en el
formato de la base de conocimiento a un nuevo formato, es posible ofrecer ese servicio como
propio, ya que si un cliente solicita ese formato, es posible utilizar ese servicio de traducción de
forma transparente al cliente. En este sentido, existe una gran cantidad de trabajos que profundizan
en el descubrimiento de SWS, que podrían ser tomados como un punto de partida.
Por otra parte, durante el desarrollo del trabajo, ha sido necesario descartar algunas mejoras e ideas
directamente relacionadas con el mismo para no extender en demasía el presente proyecto. A
continuación se enumeran algunas de estas tareas que quedarían pendientes, pero que podrían ser
contempladas para una ampliación del presente trabajo:
•
Aplicación de lógica difusa a conceptos categóricos en la ontología DATEX II: Tal como se ha
comentado en el desarrollo del trabajo, en DATEX II se definen algunos conceptos de tipo
categórico de forma abrupta, perdiendo de esta forma información. En estos casos, la aplicación de
lógica difusa puede mejorar el modelo en dos vertientes: la representación del conocimiento
dispuesto en él y el acercamiento al lenguaje natural (pensamiento humano) de los conceptos
representados. Intensidad de condiciones meteorológicas, riesgos o impactos podrían ser
características fácilmente representables utilizando esta aproximación más flexible.
•
Implementación de la pasarela DATEX II – DATEX II semántico: Aunque sí se han modelado
prácticamente todos los parámetros y conceptos del modelo DATEX II en la ontología, únicamente
se ha implementado un prototipo para la traducción. Esta pasarela ha sido plenamente válida para
las premisas planteadas, sin embargo, para futuros trabajos sería interesante disponer de una
versión completa de traducción que incluyera todos los tipos de datos para ampliar la casuística y
mejorar así la fiabilidad del modelo en los experimentos que se planteen. Después de esta
implementación sería además recomendable considerar la eficiencia de esta pasarela, buscando
optimizaciones en el código que consigan una mejora del rendimiento.
•
Persistencia en ontologías: Todos los experimentos efectuados sobre la ontología DATEX II se han
centrado en la explotación de información de modelos almacenados en memoria. Sin embargo, el
escenario típico en un ámbito aplicado, sería la integración de esta información en bases de datos
especializadas. Existen aproximaciones que permiten el almacenamiento de tripletas RDF en bases
de datos de uso general y otras que ofrecen sistemas específicos para esta tarea, en ambos casos
con excelentes resultados en cuanto a capacidad y eficiencia. Para la implantación en un sistema
real, sería necesario evaluar cuál sería la mejor solución, implementando una capa de acceso al
sistema de almacenamiento de tripletas elegido.
•
Arquitectura para la explotación de información de tráfico basada en perfiles semánticos:
Utilizando como base la arquitectura general planteada, sería posible aplicarlo al desarrollo de un
sistema de explotación de información de tráfico, llevando al diseño y a la implementación los
conceptos planteados. Para ello, se propone una infraestructura basada en agentes que se
comuniquen para la resolución de los problemas planteados. La interacción con otros servicios
podría realizarse utilizando las aproximaciones definidas para los SWS, para lo cual habría que
definir de forma semántica cada una de las características de los servicios que pudieran interactuar
con el sistema. Para la clasificación de mensajes basada en perfiles semánticos, sería necesaria la
interacción de estos agentes con un sistema basado en reglas difusas, mediante las cuales se
razonaría una ordenación de mensajes en base a las preferencias de los usuarios.
96
Glosario de términos
GLOSARIO DE TÉRMINOS
API: Interfaz de Programación de Aplicaciones
CGT: Centro de Gestión de Tráfico
DATEX: DAta Traffic Exchange
GIS: Sistema de Información Geográfica
GPS: Global Positioning System
HTML: HyperText Markup Language
ISO: International Organization for Standarization
ITS: Intelligent Transport Systems
JADE: Java Agent DEvelopement framework
KML: Keyhole Markup Language
MDA: Model Driven Architecture
OWL: Ontology Web Language
PIM: Platform Indepent Model (arquitecturas MDA)
PSM: Platform Specific Model (arquitecturas MDA)
RDF: Resource Description Framework
RDS-TMC: Traffic Message Channel utilizando Radio Data System como medio de difusión
SeRQL: Sesame RDF Query Language
SOAP: Simple Object Access Protocol
SPARQL: SPARQL Protocol and RDF Query Language
SQL: Structured Query Language
SWS: Servicios Web Semánticos
TPEG: Transport Protocol Experts Group
UML: Unified Modeling Language
URI: Uniform Resource Identifier
W3C: World Wide Web Consortium
WAR: Web Application aRchive
WSDL: Web Service Description Language
XML: eXtensible Markup Language
97
Bibliografía
BIBLIOGRAFÍA
Aduna-Software. (2009, septiembre 1). openRDF.org. Retrieved septiembre 4, 2009, from ...home of
Sesame: http://www.openrdf.org/
Alani, H., Hall, W., O’Hara, K., Shadbolt, N., Szomszor, M., & Chandler, P. (2008). Building a Pragmatic
Semantic Web. Intelligent Systems, IEEE , 61-68.
Ankolekar, A., Krötzsch, M., Tran, T., & Vrandecic, D. (2008). The two cultures: Mashing up Web 2.0 and
the Semantic Web. Web Semantics: Science, Services and Agents on the World Wide Web 6 , 70-75.
Ayers, D. (2009). Delivered Deliverables: The State of the Semantic Web, Part 1. Internet Computing,
IEEE , 13 (1), 86-89.
Baader, F., Calvanese, D., Nardi, D., & Patel-Schneider, P. (2003). The Description Logic Handbook Theory, Implementation and Applications. Cambridge.
Bachlechner, D. (2008). Toward a Semantic Web service technology roadmap. Research Challenges in
Information Science, 2008. RCIS 2008. Second International Conference on , (pp. 17 - 28). Marrakech.
Berners-Lee, T., & Dharanaj, R. (2006). Tabulator 0.8.
Berners-Lee, T., Hendler, J., & Lassila, O. (2001). The Semantic Web: A new form of Web content that is
meaningful to computers will unleash a revolution of new possibilities. Scientific American .
Biolchini, J. C., Mian, P. G., Natali, A. C., Conte, T. U., & Travassos, G. H. (2007). Scientific research
ontology to support systematic review in software engineering. Jorge Calmon de Almeida Biolchini,
Paula Gomes Mian, Ana Candida Cruz Natali, (21), 133–151.
Brewster, C., & Kieron, O. (2007). Knowledge Representation with ontologies: Present challenges—
Future possibilities. (65).
Calegari, S., & Ciucci, D. (2007). Fuzzy Ontology and Fuzzy-OWL in the KAON Project. Fuzzy Systems
Conference, 2007. FUZZ-IEEE 2007. IEEE International, (pp. 1-6).
Canós Gandía, D. (2003). Semántica en aplicaciones de tráfico basadas en DATEX II. Proyecto de fin de
carrera, Universidad de Valencia, Departamento de Informática, Valencia.
Carrillo Zambrano, E. (2004). Framework for ubiquitous and voice enabled Web applications deployment.
Tesis doctoral, Universidad de Valencia, Departamento de Informática, Valencia.
clark & parsia. (2009, junio 11). Pellet: The Open Source OWL Reasoner. Retrieved agosto 17, 2009, from
http://clarkparsia.com/pellet
Cowan, K., Sultan, B., & Burrows, J. (2008). Real-time fusion of UK traffic data. Road Transport
Information and Control - RTIC 2008 and ITS United Kingdom Members' Conference, IET, (pp. 1-8).
Manchester.
Cranefield, S., & Pan, J. (2007). Bridging the gap between the model-driven architecture and ontology
engineering. Int. J. Human-Computer Studies (65), 595–609.
d’Aquin, M., Motta, E., Sabou, M., Angeletou, S., Gridinoc, L., Lopez, V., et al. (2008). Toward a New
Generation of Semantic Web Applications. Intelligent Systems, IEEE , 23 (3), 20 - 28.
99
DATEX II TC. (2007). datex2. Retrieved agosto 8, 2009, from http://www.datex2.eu
Davis, R. (2001). Knowledge Representation (Vol. 14). New York University, New York, USA: Elsevier Ltd.
All rights reserved.
DGT. (2009). DGT - etraffic. Retrieved agosto 19, 2009, from http://infocar.dgt.es/etraffic/
Díaz, M. D. (2006). Métrica y Complejidad del software. Retrieved septiembre 2, 2009, from
http://www.moisesdaniel.com/es/wri/torometrics.htm
Díaz, M. D. (2005, diciembre 19). ToroMetrics v1.0.
Ding, Z., & Peng, Y. (2004). A probabilistic extension to ontology language OWL. System Sciences, 2004.
Proceedings of the 37th Annual Hawaii International Conference on, (p. 10). Hawaii.
ERTICO - ITS Europe. (2007). ERTICO. Retrieved agosto 18, 2009, from http://www.ertico.com/
Fensel, D., & Bussler, C. (2002). Semantic Web enabled Web Services. In Proceedings of the International
Semantic Web Conference 2002 (pp. 1-2). Springer.
foaf project. (2009). The Friend of a Friend (FOAF) project. Retrieved septiembre 10, 2009, from
http://www.foaf-project.org/
Galindo Gómez, J. (2009). Curso Introductorio de Conjuntos y Sistemas Difusos (Lógica Difusa y
Aplicaciones). Málaga, España: Universidad de Málaga.
García Calderaro, J. F., Vidal Peña, J., Pérez Losa, P. A., López López, B., & Torres Garrigós, D. (2007).
DATEX II: El nuevo estándar para el intercambio y publicación de información de tráfico en Europa.
Situación en España. VII Congreso ITS España – Valencia. Valencia.
GaSevid, D., Djuric, D., Devediid, V., & Damjanovid, V. (2004). Ontologies, From UML to Ready-To-Use
OWL. Second lEEE International Conference On Intelligen Systems.
Gene Ontology Consortium. (2000). Gene Ontology: tool for the unification of biology. Nature America
Inc. http://genetics.nature.com .
Gene Ontology Consortium. (2009, julio 10). the Gene Ontology. Retrieved julio 21, 2009, from
http://www.geneontology.org/
Ghosh, R., & Dekhil, M. (2008). Mashups for Semantic User Profiles. In ACM (Ed.), International World
Wide Web Conference - Proceeding of the 17th international conference on World Wide Web (pp. 12291230). Beijing, China : AMC.
Greenwood, D., & Calisti, M. (2004). Engineering Web service - agent integration. Systems, Man and
Cybernetics, 2004 IEEE International Conference on, 2, pp. 1918-1925. Zurich.
Gruber, T. (1993). A translation approach to portable ontology specifications. Knowledge Acquisition
Journal , Vol. 5, 199-200.
Hahn, C., Nesbigall, S., Warwas, S., Zinnikus, I., Fischer, K., & Klusch, M. (2008). Integration of Multiagent
Systems and Semantic Web Services on a Platform Independent Level. Web Intelligence and Intelligent
Agent Technology, 2008. WI-IAT '08. IEEE/WIC/ACM International Conference on, 2, pp. 200-206.
Sydney.
100
Bibliografía
Hepp, M. (2006). Semantic Web and semantic Web services: father and son or indivisible twins? Internet
Computing, IEEE , 85-88.
Horrocks, I., & Patel-Scheneider, P. (2004). Reducing OWL entailment to description logic satisfiability.
International Semantic Web Conference 2003, 1, pp. 345-357.
Houben, G.-J., Aerts, A., Aroyo, L., Sluijs, K. v., Rutten, B., & Bra, P. D. (2005). State of the art semantic
interoperability for distributed user profiles. Technical Report, Telematica Institute.
ISO. (2003). ISO 2003, Traffic and Traveler Information (TTI) - TTI messages via traffic message coding.
Suiza: ISO.
JADE community. (2009, Julio 2). Java Agent DEvelopement Framework. (Telecom Italia Spa) Retrieved
septiembre 14, 2009, from an Open Source platform for peer-to-peer agent based applications:
http://jade.tilab.com/
Jaramillo, P. (2009). Toma de decisiones con base en lógica difusa. Medellín, Colombia: Universidad
Nacional de Colombia, Sede Medellín.
Jena team. (2009, mayo 18). Jena – A Semantic Web Framework for Java . Retrieved julio 14, 2009, from
http://jena.sourceforge.net/
Jena team. (2008, abril 4). Jena schemagen HOWTO. Retrieved julio 14, 2009, from
http://jena.sourceforge.net/how-to/schemagen.html
Jena team. (2009, agosto
http://jena.hpl.hp.com/wiki/TDB
25).
TDB.
Retrieved
septiembre
2,
2009,
from
Jena:
Kim, J.-M., Choi, B.-I., Shin, H.-P., & Kim, H.-J. (2007). A methodology for constructing of philosophy
ontology based on philosophical texts. Computer Standards & Interfaces (29), 302–315.
Ko, M. S., Kim, Y. H., Kim, B. G., Lee, J., & Lim, H. C. (2005). The Storage and Retrieval System for Online
News Based on OWL. Advanced Communication Technology, 2005, ICACT 2005. The 7th International
Conference on, 2, pp. 1360-1364.
Langegger, A., Blöchl, M., & Wöß, W. (2007). Sharing Data on the Grid using Ontologies and distributed
SPARQL Queries. 18th International Workshop on Database and Expert Systems Applications.
Lee, C.-S., Jian, Z.-W., & Huang, L.-K. (2005). A fuzzy ontology and its application to news summarization.
Systems, Man, and Cybernetics, Part B: Cybernetics, IEEE Transactions on, 35, pp. 859-880. Tainan,
Taiwan.
Liu, J. N. (2007). Fuzzy Ontology Based System for Product Management and Recommendation.
International Journal Of Computers , 1 (3).
Manuel Noguera, M. V. (2009). Ontology-driven Analysis of UML-Based Collaborative Processes using
OWL-DL and CPN. Science of Computer Programming .
Mariano Fernández, A. G.-P. (1997). METHONTOLOGY:From Ontological Art Towards Ontological
Engineering. Madrid, Spain: AAAI Technical Report SS-97-06.
Martin, D., Burstein, M., McDermott, D., McIlraith, S., Sycara, M. P., McGuinness, D. L., et al. (2007).
Bringing Semantics to Web Services with OWL-S. World Wide Web , 10 (3), 243-277.
101
Martín, G., & Martín, I. (2005). Curso de XML: Introducción al lenguaje de la Web (1 ed.). Madrid:
Pearson Educacion.
McCabe, T. J. (1976). A Complexity Measure. IEEE Transactions on software engineering , SE-2 (4).
McIlraith, S., Son, T., & Zeng, H. (2001). Semantic Web services. Intelligent Systems, IEEE , 46-53.
Morbach, J., Yang, A., & Marquardt, W. (2007). OntoCAPE—A large-scale ontology for chemical process
engineering. Engineering Applications of Artificial Intelligence (20), 147–161.
Neiat, A., Mohsenzadeh, M., Shavalady, S., & Rahmani, A. (2009). A New Approach for Semantic Web
Service Discovery and Propagation Based on Agents. Networking and Services, 2009. ICNS '09. Fifth
International Conference on, (pp. 37-42). Valencia.
Neto, D. (2008). Sizeof for Java.
Nicola, A. d., Missikoff, M., & Navigli, R. (2009). A software engineering approach to ontology building.
Information Systems (34), 258–275.
Noy, N. F., & McGuinness, D. L. (2001). Ontology Development 101: A Guide to Creating Your First
Ontology. Stanford University, Stanford, CA, 94305.
Noy, N. F., & Rubin, D. L. (2008). Translating the Foundational Model of Anatomy into OWL. Web
Semantics: Science, Services and Agents on the World Wide Web (6), 133-136.
Oporto Díaz, M. S. (2005). Introducción a la Lógica Difusa - Variables Lingüisticas y Lógica Difusa.
OWL-S Coalition. (2008, diciembre). OWL-S: Semantic Markup for Web Services. Retrieved septiembre 8,
2009, from http://www.ai.sri.com/daml/services/owl-s/1.2/overview/
protégé team. (2009, julio). OWL ontologies. Retrieved julio 21, 2009, from Protege Ontology Library:
http://protegewiki.stanford.edu/index.php/Protege_Ontology_Library#OWL_ontologies
protégé team. (2009, junio 14). Protégé 4. Retrieved julio 14, 2009, from http://protege.stanford.edu/
protégé team. (2009, agosto 14). WebProtégé 0.5.
Pulido, J., Ruiz, M., Herrera, R., Cabello, E., Legrand, S., & Elliman, D. (2006). Ontology languages for the
semantic web: A never completely updated review. Knowledge-Based Systems , 489-497.
Radio Nacional de España S.A. (2005). El servicio RDS-TMC en RNE. Retrieved agosto 17, 2009, from
http://www.rtve.es/rne/emisoras/rds.htm#TMC
Raines, A., & Rowley, P. (2008). Coordinated traffic management through data exchange. Road
Transport Information and Control - RTIC 2008 and ITS United Kingdom Members' Conference, IET, (pp.
1-4). Manchester.
Sáez Esteve, A. (2007). Un sistema experto basado en reglas, para la gestión dinámica de estrategias de
tráfico. Proyecto de Investigación, Universidad de Valencia, Departamento de Informática, Valencia.
Samper Zapater, J. J. (2005). Ontologías para Servicios Web Semánticos de Información de Tráfico:
Descripción y Herramientas de Explotación. Tesis doctoral, Universidad de Valencia, Departamento de
Informática, Valencia.
102
Bibliografía
Samper Zapater, J. J., Adell, J., García Calderario, J., Martínez Durá, J., & Vidal Peña, J. (2009). Semantic
traffic applications based on DatexII. Euro American Conference On Telematics And Information Systems.
Praga, República Checa.
Samper Zapater, J. J., Tomás, V. R., Carrillo, E., & Nascimento, R. P. (2008). Visualization of Ontologies to
Specify Semantic Descriptions of Services. IEEE Transactions on Knowledge and Data Engineering , 20
(1).
Samper Zapater, J. J., Tomás, V. R., Martinez, J. J., & Berg, L. v. (2006). An Ontological Infrastructure for
Traveller Information Systems. 2006 IEEE Intelligent Transportation Systems Conference, TC6.1. Toronto,
Canada.
Sarder, M. B., & Ferreira, S. (2007). Developing Systems Engineering Ontologies. IEEE .
Sarraipa, J., Silva, J. P., Jardim-Gonçalves, R., & Monteiro, A. A. (2008). MENTOR – A Methodology for
Enterprise Reference Ontology Development. 2008 4th International IEEE Conference "Intelligent
Systems" .
Shao, Y., Li, L., Du, Z., & Qi, Q. (2008). The Research on Ontology-Driven Semantic Retrieval of Enterprise
Data. Intelligent Networks and Intelligent Systems, 2008. ICINIS '08. First International Workshop on, (pp.
729-732). Wuhan.
Simperl, & Elena. (2009). Reusing ontologies on the Semantic Web: A feasibility study. Data &
Knowledge Engineering .
Simperl, E., Popov, I. O., & Bürger, T. (2009). ONTOCOM Revisited: Towards Accurate Cost Predictions
for Ontology Development Projects. Proceedings of the European Semantic Web Conference 2009 (ESWC
'09). Heraklion, Greece.
Sinner, A., Kleemann, T., & Hessling, A. v. (2004). Semantic User Profiles and their Applications in a
Mobile Environment. Artificial Intelligence in Mobile Systems 2004 .
Sowa, J. F. (1999). Knowledge Representation: Logical, Philosophical, and Computational Foundations.
Brooks Cole Publishing Co., Pacific Grove, CA.
Staab, S., Brewster, C., & O’Hara, K. (2004). Knowledge Representation with Ontologies: The Present and
Future.
Stoilos, G., Simou, N., Stamou, G., & Kollias, S. (2006). Uncertainty and the Semantic Web. (S. Staab, Ed.)
Intelligent Systems, IEEE , 21 (5), 84-87.
Stoilos, G., Stamou, G., Tzouvaras, V., Pan, J., & Horrocks, I. (2005). Fuzzy OWL: Uncertainty and the
Semantic Web. Proc. of the International Workshop on OWL: Experiences and Directions (2005), 280.
The Open Biomedical Ontologies. (2009, julio 21). The Open Biomedical Ontologies. Retrieved julio 21,
2009, from http://obofoundry.org/
The Parliamentary Office of Science and Technology. (2009). Intelligent Transport Systems. postnote
(322).
Tomás López, V. R. (2006). Tácticas mixtas para la negociación automática de múltiples servicios con
información incompleta en entornos multiagente. Aplicación a problemas de gestión de tráfico. Tesis
doctoral, Universidad de Valencia, Departamente de Informática, Valencia.
103
Torres Garrigós, D. (2007). Adaptación de un servidor RDS-TMC - Administración de Andorra. Proyecto
de fin de carrera, Universidad de Valencia, Departamento de Informática, Valencia.
Tsarkov, D., & Horrocks, I. (2009, mayo 29). FaCT++. Retrieved julio 14, 2009, from
http://owl.man.ac.uk/factplusplus
U.S. Department of Transportation. (2007, enero 12). Intelligent Transportation Systems for Traveler
Information. Retrieved junio 18, 2009, from
http://www.its.dot.gov/jpodocs/repts_te/14319_files/14319.pdf
Umar, A., & Zordan, A. (2009). Enterprise Ontologies for Planning and Integration of Business: A
Pragmatic Approach. IEEE Transactions On Engineering Management , 56 (2).
Via Michelin. (2006). Via Michelin Navigation X-950T.
W3C - OWL Working Group. (2008, enero 18). EL. Retrieved julio 22, 2009, from W3C OWL Working
Group: http://www.w3.org/2007/OWL/wiki/EL
W3C - OWL Working Group. (2009, marzo 27). OWL 2 Web Ontology Language Document Overview.
Retrieved agosto 16, 2009, from W3C: http://www.w3.org/TR/2009/WD-owl2-overview-20090327/
W3C - OWL Working Group. (2009, junio 11). OWL 2 Web Ontology Language Primer. Retrieved julio 21,
2009, from W3C: http://www.w3.org/TR/owl2-primer/
W3C - OWL Working Group. (2004, febrero 24). OWL Web Ontology Language - Use Cases and
Requirements. Retrieved agosto 17, 2009, from W3C: http://www.w3.org/TR/webont-req/
W3C - OWL Working Group. (2004, febrero 10). OWL Web Ontology Language Guide. Retrieved julio 21,
2009, from W3C: http://www.w3.org/TR/owl-guide/
W3C - RDF Data Access Working Group. (2009, julio 19). Joseki 3.4.
W3C - RDF Working Group. (2009, abril 30). Resource Description Framework (RDF). Retrieved julio 21,
2009, from W3C: http://www.w3.org/RDF/
W3C - Semantic Web Interest Group. (2009, abril 20). Basic Geo (WGS84 lat/long) Vocabulary. Retrieved
septiembre 14, 2009, from http://www.w3.org/2003/01/geo
W3C - Semantic Web Working Group. (2009, Julio 20). W3C Semantic Web Activity. Retrieved from W3C:
http://www.w3.org/2001/sw/
W3C - SPARQL Working Group. (2008, enero 15). SPARQL Protocol for RDF. Retrieved julio 22, 2009,
from W3C: http://www.w3.org/TR/rdf-sparql-protocol/
W3C - SPARQL Working Group. (2008, enero 15). SPARQL Query Language for RDF. Retrieved julio 22,
2009, from W3C: http://www.w3.org/TR/rdf-sparql-query/
W3C - SPARQL Working Group. (2008, enero 15). SPARQL Query Results XML Format. Retrieved julio 22,
2009, from W3C: http://www.w3.org/TR/rdf-sparql-XMLres/
W3C Working Group. (2004, febrero 11). Web Services Architecture. Retrieved septiembre 4, 2009, from
www.w3.org/TR/ws-arch/
Wei-feng, L., Wei, C., & Jian, H. (2008). Research on a DATEX II Based Dynamic Traffic Information
Publish Platform., (pp. 412-416 ). Beijing.
104
Bibliografía
Wikipedia. (2009, julio). Description logics. Retrieved julio 22, 2009, from
http://en.wikipedia.org/wiki/Description_logic
Wongthongtham, P., Dillon, D., Dillon, T., & Chang, E. (2008). Use of UML 2.1 to Model Multi-Agent
Systems based on a Goal-driven Software Engineering Ontology. Fourth International Conference on
Semantics, Knowledge and Grid.
XMLBeans Community. (2009, junio 8). Apache XMLBeans. Retrieved julio 10, 2009, from The APACHE
XML project: http://xmlbeans.apache.org
Yu, Q., & Wang, J. (2007). Extending Ontology Language for Semantic Web. 2007 International
Conference on Computational Intelligence and Security Workshops. IEEE Computer Society.
Zadeh, L. (1965). Fuzzy Sets. Information and Control , 338-353.
Zadeh, L. (1975). The concept of a linguistic variable and its application to approximate reasoning.
Information sciences (1), 199-249.
Zhai, J., Cao, Y., & Chen, Y. (2008). Semantic information retrieval based on fuzzy ontology for intelligent
transportation systems. Systems, Man and Cybernetics, 2008. SMC 2008. IEEE International Conference
on, (pp. 2321-2326). Singapore.
Zhai, J., Shen, L., Liang, Y., & Jiang, J. (2008). Application of Fuzzy Ontology to Information Retrieval for
Electronic Commerce. Electronic Commerce and Security, 2008 International Symposium on, (pp. 221225). Guangzhou City.
Zhai, J., Yu, Y., Liang, Y., & Jiang, J. (2008). Traffic Information Retrieval Based on Fuzzy Ontology and RDF
on the Semantic Web. Intelligent Information Technology Application, 2008. IITA '08. Second
International Symposium on, 3, pp. 779-784.
Zhang, X., & Li, W. (2008). Ontology-based Semantic Retrieval System. Wireless Communications,
Networking and Mobile Computing, 2008. WiCOM '08. 4th International Conference on. Dalian.
zhihong, Z., & mingtian, Z. (2003). Web Ontology Language OWL and Its Description Logic Foundation.
IEEE .
Zolin, E. (2007, julio 27). Complexity of reasoning in Description Logics. Retrieved julio 22, 2009, from
http://www.cs.man.ac.uk/~ezolin/dl/
105
Anexo I - DATEX II
ANEXO I
DATEX II
El propósito del presente anexo es definir de forma rápida algunas de las características técnicas más
importantes de DATEX II, de forma que facilite al lector la comprensión de algunos de los términos que
aparecen en el trabajo.
I.1
MODELO DE DATOS
El modelo de datos de DATEX II se basa en publicaciones. Una publicación es una agrupación de datos
que coinciden en una temática o propósito y es única en un mensaje DATEX II.
DATEX I soportaba únicamente situaciones de tráfico como tipo de información intercambiable. En
DATEX II se añaden además otros tipos de publicaciones:
•
Datos de medida: Medidas en bruto referentes al tráfico o al tiempo atmosférico.
•
Puntos de medida: Lugares donde se efectúan medidas sobre el tráfico (ETD).
•
Datos elaborados: Medidas de tráfico calculadas a partir de datos de tráfico.
•
Vistas de tráfico: Conjunto de situaciones y datos en un tramo de una carretera. Ofrecen una “vista”
de toda la información disponible sobre un tramo predefinido.
•
Localizaciones predefinidas: Conjunto de localizaciones fijas, referidas normalmente a puntos o
tramos con ciertas características especiales.
•
Publicación genérica: Utilidad para la extensión del modelo. Posibilita la creación de publicaciones
personalizadas en base a las necesidades de cada entidad.
Figura 47: Tipos de publicaciones según DATEX II
107
Cabe destacar además los tipos de localizaciones que se pueden representar en DATEX II16:
•
Alert-C: Codificación mediante ISO 14819-2 (ISO, 2003). Se referencian unas tablas predefinidas de
puntos que catalogan las localizaciones de cada país o región.
•
Coordenadas geográficas: Coordenadas en base a WGS84, basadas en latitud y longitud.
•
TPEG-Loc: Sistema de localización preestándar, posible substituto futuro de Alert-C. No se basa en
una tabla predefinida, sino que se definen las localizaciones ad hoc, incluyendo toda la información
geográfica necesaria para su representación gráfica.
•
Reference Locations: Incluye información básica para las localizaciones de un suceso, como
carretera, punto kilométrico, etc.
I.2
MODELO DE INTERCAMBIO
El modelo de intercambio de DATEX II amplía al de DATEX I, en el cual el funcionamiento era siempre de
tipo PUSH, es decir, el proveedor enviaba al cliente la información conforme se iba produciendo. Este
método no es siempre óptimo en todos los escenarios de implantación, por lo que se han permitido las
peticiones PULL, en las cuales el cliente solicita la información al proveedor. Este modelo, utilizado
actualmente en Internet, facilita en gran medida la publicación de información por parte de una entidad
proveedora, que generalmente sólo deberá ofrecer una URL en la que pondrá toda su información
disponible para que terceros puedan explotarla de forma directa.
PUSH
PULL
Funcionamiento
El cliente recoge toda la información activa
Fiabilidad
Muy fiable, se actualiza en cada acceso
toda la información del servidor
Sencillez
Implementación sencilla
Eficiencia
Redundancia en el envío de información
Acceso
HTTP, SOAP
El servidor manda al cliente únicamente los
cambios conforme se vayan produciendo
Necesita mecanismos adicionales para
asegurar la integridad de la información
Complejo, requiere una subscripción previa y
comparar eventos
Eficiente, sólo se envía la información
necesaria
SOAP
Tabla 9: Comparativa entre modelos de intercambio vía DATEX II
I.3
HERRAMIENTA DTX2
Herramienta DTX2 es el nombre comercial del nodo DATEX II desarrollado por IR-LISITT. Cubre una gran
parte del estándar, ofreciendo opciones adicionales de filtrado. Se encuentra en fase de desarrollo
actualmente y soporta la versión 1.0 del modelo.
16
Estos tipos no son en ningún caso excluyentes, por lo que pueden combinarse de la forma mejor para detallar al
máximo la localización del evento.
108
Anexo I - DATEX II
Figura 48: Arquitectura lógica de la aplicación Herramienta DTX2
La aplicación incluye, entre otras herramientas, un sistema de administración para la gestión del nodo:
subscripciones, usuarios, etc.
Figura 49: Capturas de pantalla de la herramienta de administración de la aplicación Herramienta DTX2
Se espera que un futuro sean implementadas otras funcionalidades como un visor georreferenciado o
un módulo de publicación de información vía RDS-TMC.
109
Anexo II - Lógica difusa aplicada a ontologías
ANEXO II
LÓGICA DIFUSA APLICADA A ONTOLOGÍAS
En (Zadeh, Fuzzy Sets, 1965) se enunció por primera vez el concepto de conjunto difuso. La lógica clásica
(también conocida como bivaluada ya que sólo se aceptan dos valores) es demasiado restrictiva, una
afirmación en el mundo real puede no ser estrictamente CIERTA o estrictamente FALSA, sino algo
intermedio. Mediante lógica difusa es posible representar este tipo de información imprecisa.
Desde la aparición de la teoría, se ha desarrollado todo un campo de investigación con multitud de
aplicaciones: control de sistemas, predicción y optimización, reconocimiento de patrones y sistemas de
representación del conocimiento.
En los siguientes apartados se efectúa una visión general sobre la lógica difusa, en especial sobre la
definición de variables lingüísticas, que tendrán un uso clave para los trabajos desarrollados, finalizando
con la aplicación a ontologías, un área de investigación que se encuentra bastante activo en la
actualidad.
II.1
CONJUNTOS Y LÓGICA DIFUSA
En (Galindo Gómez, 2009), se define un conjunto difuso A como una Función de Pertenencia que enlaza
o empareja los elementos de un dominio o Universo de discurso X con elementos del intervalo [0, 1]:
Generaliza de esta forma a los conjuntos habituales (llamados crisp) en los cuales un objeto debe
pertenecer o no al conjunto, sin ningún grado de incertidumbre. De esta forma pueden reflejarse
algunas ideas del mundo real que de otra forma son definidas de forma muy forzada17.
Se representa habitualmente mediante una función de forma gráfica, en la cual las abscisas son el
universo de discurso X y las ordenadas los grados de pertenencia en el intervalo [0, 1].
Figura 50: Ejemplo de representación gráfica de la función de pertenencia "Temperatura Alta" (Galindo Gómez, 2009)
Existe una gran tipología en las formas de las funciones de pertenencia, desde trapezoides hasta
mixturas de gaussianas, mediante las cuales es posible modelar cualquier comportamiento de una
función de pertenencia.
17
Un ejemplo de ello sería la extraña pero sin embargo muy habitual idea de que alguien deje de ser joven de la
noche a la mañana por haber cumplido un número determinado de años (Jaramillo, 2009).
111
Para los conjuntos difusos se pueden aplicar muchas de las propiedades, operaciones y teoremas de los
conjuntos crisp, aunque expresados de forma generalizada para tener en cuenta la incertidumbre en la
pertenencia de los elementos de los conjuntos. Por ejemplo, se definen modelos genéricos para las
operaciones de unión e intersección de conjuntos difusos (t-normas y s-normas respectivamente),
cumpliendo todas las propiedades básicas habituales (conmutativa, asociativa, monotonicidad y
condiciones frontera).
Al igual que se extienden los conjuntos crisp a los conjuntos difusos, se extiende la lógica proposicional y
la lógica de predicados a la lógica difusa, mediante la inclusión de un grado de verdad. Las afirmaciones
que se efectúan ya no necesitan ser CIERTAS o FALSAS, sino que pueden ser cuantificadas mediante un
valor [0, 1]. Esta lógica difusa tiene multitud de aplicaciones para sistemas basados en reglas al
flexibilizar la resolución de problemas y la toma de decisiones de estos sistemas.
Otra posibilidad interesante en el uso de lógica difusa es la declaración de variables lingüísticas en lugar
de valores numéricos, lo cual aproxima al lenguaje natural los enunciados de la lógica difusa.
II.2
VARIABLES LINGÜÍSTICAS
En (Zadeh, The concept of a linguistic variable and its application to approximate reasoning, 1975) se
detalló el concepto de variable lingüística como sustituto de los grados de verdad aplicados a la lógica
difusa.
Se define una variable lingüística como una variable cuyos valores son palabras o sentencias (no
números) y que se utiliza para describir el estado de un objeto o fenómeno. Los valores que definen una
variable lingüística son etiquetas lingüísticas, que son términos lingüísticos definidos a su vez como
conjuntos difusos.
Figura 51: Ejemplo de variable lingüística "Edad" (Oporto Díaz, 2005)
Zadeh define formalmente una variable lingüística como una 5-tupla de la forma:
Siendo:

N el nombre de la variable (“Edad”).

U el universo subyacente (Edad en años).

T(N) el conjunto de etiquetas que puede tomar N (Joven, Mediana Edad y Viejo).
112
Anexo II - Lógica difusa aplicada a ontologías

G una gramática formal para generar las etiquetas de T(N) (definición de que el modificador MUY
iría antes de la etiqueta JOVEN).

M una regla semántica que asocia cada elemento de T(N) con un conjunto difuso en U (gráfico de
funciones de pertenencia).
En la gramática G es posible introducir modificadores lingüísticos formalmente, elevando las funciones
de pertenencia a un parámetro p con un valor variable, potenciando así la flexibilidad de la gramática.
Existen operadores de concentración (elevando a p > 1), de dilatación (elevando a p < 1), o de
intensificación del contraste y difuminación (elevando una parte a p > 1 y otra parte a p < 1).
Figura 52: Ejemplo de modificadores lingüísticos de concentración y dilatación para una etiqueta L
II.3
SISTEMAS BASADOS EN REGLAS
Se define una regla (Galindo Gómez, 2009) como “un modo de representar estrategias o técnicas
apropiadas cuando el conocimiento proviene de la experiencia o de la intuición (careciendo de
demostración matemática y física)”.
En las reglas, se precisa una proposición formada por una cláusula antecedente o condición que provoca
cuando se cumple, que sea cierto el contenido de la cláusula consecuente o conclusión. Para el caso de
lógica difusa, estas dos cláusulas se expresarían de forma borrosa.
Un ejemplo de regla que utilizaría lógica difusa podría ser: “SI el Agua está sucia ENTONCES añadir un
poco de jabón”. Los conceptos sucio y poco son afirmaciones difusas, pero que tendrían una aplicación
interesante en un sistema de control de un lavavajillas, evitando realizar complicados cálculos.
Coinciden con los sistemas basados en reglas habituales en gran parte de su sintaxis y de las
propiedades que se pueden aplicar, añadiendo otras nuevas como la posibilidad de cualificar y
cuantificar las proposiciones. Las proposiciones cualificadas permiten añadir grados de certeza,
probabilidad y posibilidad, mientras que las proposiciones cuantificadas añaden a los cuantificadores
universal y existencial, otros cuantificadores difusos (la mayoría, muchos, aproximadamente 6, etc.).
113
II.4
LÓGICA DIFUSA EN ONTOLOGÍAS
Uno de los campos de aplicación de la lógica difusa ha sido la representación del conocimiento, en
especial en los últimos años y después de la aparición del concepto de ontología aplicado a la Web
Semántica.
En (Stoilos, Stamou, Tzouvaras, Pan, & Horrocks, 2005) y más tarde en (Stoilos, Simou, Stamou, &
Kollias, 2006) se puso de manifiesto que en la actual Web Semántica es compleja la representación de
algunos conceptos imprecisos (“alto”, “azul”, “poco”), proponiendo la utilización de una aproximación
basada en lógica difusa para representar este tipo de conocimiento: Fuzzy OWL. Esta extensión de OWL
ofrece nuevas etiquetas para describir tipos de inecuaciones y grados, características necesarias para la
definición de las variables difusas.
Han aparecido sin embargo otras aproximaciones similares, como por ejemplo FOWL (Yu & Wang,
2007), con lo que no existe un consenso generalizado para el uso de ontologías con información difusa.
Aunque muchos autores sí se han decantado por la descripción original en la aplicación a sus proyectos
(Calegari & Ciucci, 2007), la opción más observada en el mundo académico para este campo es que cada
grupo construya su propia aproximación difusa para el dominio específico con el que esté trabajando.
Por ejemplo, en (Lee, Jian, & Huang, 2005) se construyó una ontología para la clasificación de noticias
según temática e importancia, y en (Zhai, Yu, Liang, & Jiang, 2008) se aplicaron los conceptos de variable
y etiqueta lingüística para definir algunos conceptos imprecisos relacionados con el tráfico, no utilizando
en este caso grados numéricos de pertenencia.
En este último artículo se incluían parámetros específicos para análisis de accidentes a posteriori (edad y
estado del conductor, velocidad del vehículo, condiciones de la carretera, tiempo atmosférico),
utilizándolos para la extracción de información de forma imprecisa de la base de conocimiento. Un
aspecto a destacar es que la extracción de la información se realizaba mediante un lenguaje de consulta
semántico, mediante consultas del tipo:
SELECT traffic accident
FROM
{traffic accident } ex: vehicle {} ex: speed {speed}
WHERE speed = “fast”
114
Anexo III - Definición de consultas
ANEXO III
DEFINICIÓN DE CONSULTAS
A continuación se introduce un listado de las consultas planteadas, incluyendo una definición de la
interfaz de la consulta y una pequeña explicación del propósito de la misma.
III.1 CONSULTA Q1: ESCENARIOS
Definición
Situaciones de un escenario
ENTRADA: Identificador de escenario
SALIDA: Listado básico de situaciones
Propósito
Búsqueda de un escenario concreto y obtención de un listado de situaciones para cada uno de ellos.
III.2 CONSULTA Q2: SITUACIONES
Definición
Información de una situación
ENTRADA: Identificador de situación
SALIDA: Información completa de situación
Propósito
Obtiene información sobre una situación concreta, recogiendo toda la información posible de primer nivel, además
de las localizaciones asociadas y el escenario al que pertenece.
III.3 CONSULTA Q3: SITUACIONES RECIENTES
Definición
Situaciones desde una fecha y ordenadas por campo fecha
ENTRADA: Fecha y hora de corte
SALIDA: Listado básico de situaciones, ordenado según fecha
Propósito
Obtiene aquellas situaciones más recientes a partir de una fecha concreta, ordenando estas situaciones según la
fecha, de evento más nuevo a más antiguo.
115
III.4 CONSULTA Q4: SITUACIONES POR TIPO
Definición
Listado de situaciones por tipo
ENTRADA: Tipo de situación
Propósito
Lista todas las situaciones que pertenezcan a un tipo determinado (o a sus hijos utilizando herencia).
III.5 CONSULTA Q5: ACCIDENTES CON OBJETOS PELIGROSOS
Definición
Listado de accidentes con objetos peligrosos involucrados
ENTRADA: Ninguna
Propósito
Obtiene un listado de accidentes en los que se ha visto involucrado un objeto peligroso, ya sea porque ha
provocado el accidente o porque podría provocar nuevas situaciones de peligro.
III.6 CONSULTA Q6: SITUACIONES DENTRO DE RANGO ALERT-C
Definición
Listado de situaciones dentro de un rango definido por un punto Alert-C
ENTRADA: Código Alert-C
SALIDA: Listado básico de situaciones, incluyendo información de localización
Propósito
Obtiene un listado de aquellas situaciones cuyo rango de localizaciones Alert-C pase por un punto definido.
III.7 CONSULTA Q7: SITUACIONES RELACIONADAS (CONTINUIDAD)
Definición
Listado de situaciones que tienen en común un código Alert-C
ENTRADA: Ninguna
SALIDA: Listado básico de situaciones, incluyendo información de localización
Propósito
Obtiene aquellas situaciones que están relacionadas por localización (situaciones que empiezan en un punto que es
el fin de otra o viceversa).
116
Anexo IV - Recursos disponibles
ANEXO IV
RECURSOS DISPONIBLES
En el presente anexo se presentan algunas herramientas de terceros que trabajan con la Web Semántica
y que han ayudado al testeo de las aplicaciones desarrolladas y a la presentación de información y
resultados.
IV.1 WEBPROTÉGÉ
WebProtégé (protégé team, 2009) es una aplicación Web orientada a la visualización de ontologías en
un ambiente muy parecido a la aplicación de escritorio Protégé. Puede actuar además como editor bajo
ciertas condiciones de configuración.
Para la visualización sencilla de la ontología DATEX II se ha desplegado y configurado la versión actual de
esta herramienta, que aunque se encuentra en fase de desarrollo, ofrece la funcionalidad necesaria para
la visualización de las características principales de la ontología.
Figura 53: Vista de la utilidad WebProtégé para la clase Accident
IV.2 JOSEKI
Joseki (W3C - RDF Data Access Working Group, 2009), también conocido como SPARQLer, es un
procesador de consultas SPARQL que utiliza Jena como base.
Este servidor se distribuye mediante una librería y un conjunto de ficheros que forman una aplicación
Web, que es necesario configurar y empaquetar en un fichero WAR para su despliegue en un servidor.
Joseki ha sido ampliamente utilizado durante el desarrollo para el testeo rápido de consultas SPARQL.
117
Figura 54: Formulario de entrada de consultas SPARQL de Joseki
Figura 55: Resultados de una consulta SPARQL en Joseki
IV.3 TABULATOR
Ideado por el propio Tim Berners-Lee, Tabulator (Berners-Lee & Dharanaj, Tabulator 0.8, 2006) es un
proyecto para el desarrollo de un navegador genérico basado en RDF.
Es posible acceder a la actual versión (0.8) de forma online, aunque el servicio parece ser muy inestable
y da bastantes problemas, debido seguramente a que el proyecto está parado desde 2006 y no se ha
actualizado, por lo tanto, la compatibilidad con el navegador.
118
Anexo IV - Recursos disponibles
Figura 56: Vista general de Tabulator, navegador semántico
En cualquier caso y aunque la calidad de la aplicación no es muy alta, ha podido ser utilizado como
utilidad de acceso a la base de conocimiento, obteniendo resultados de ella mediante una consulta
SPARQL. Una característica interesante de este navegador es que, si en los resultados de la consulta se
incluye información geográfica según la ontología Basic Geo (W3C - Semantic Web Interest Group,
2009), el propio navegador se encarga de ofrecer automáticamente una vista de la información de
forma geolocalizada, sin requerir para ello ninguna acción adicional por parte del usuario. En el
transcurso del trabajo se ha incluido un ejemplo gráfico de ello (ver Figura 46).
119

Evolución de DATEX II a un modelo semántico

Transcripción

Documentos relacionados

Mapa de Servicio de Madrugada