Evolución de DATEX II a un modelo semántico
Transcripción
Evolución de DATEX II a un modelo semántico
UNIVERSIDAD DE VALENCIA DEPARTAMENTO DE INFORMÁTICA Evolución de DATEX II a un modelo semántico 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… Evolución de DATEX II a un modelo semántico 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 Evolución de DATEX II a un modelo semántico 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 Evolución de DATEX II a un modelo semántico 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 Evolución de DATEX II a un modelo semántico Í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 Evolución de DATEX II a un modelo semántico 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 40: Eficiencia de la ejecución para la consulta Q4 ........................................................................... 82 Figura 41: Eficiencia de la ejecución para la consulta Q5 ........................................................................... 83 Figura 42: Eficiencia de la ejecución para la consulta Q6 ........................................................................... 84 Figura 43: Eficiencia de la ejecución para la consulta Q7 ........................................................................... 85 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 Evolución de DATEX II a un modelo semántico 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 Evolución de DATEX II a un modelo semántico 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 Evolución de DATEX II a un modelo semántico • 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 Evolución de DATEX II a un modelo semántico 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 Evolución de DATEX II a un modelo semántico 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 Evolución de DATEX II a un modelo semántico 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 Evolución de DATEX II a un modelo semántico 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 Evolución de DATEX II a un modelo semántico • 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 Evolución de DATEX II a un modelo semántico 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 Evolución de DATEX II a un modelo semántico 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 Evolución de DATEX II a un modelo semántico 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 Evolución de DATEX II a un modelo semántico 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 Evolución de DATEX II a un modelo semántico • 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 Evolución de DATEX II a un modelo semántico 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 Evolución de DATEX II a un modelo semántico 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 Evolución de DATEX II a un modelo semántico 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 Evolución de DATEX II a un modelo semántico 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 Evolución de DATEX II a un modelo semántico • 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 3. Semántica aplicada a DATEX II 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 Evolución de DATEX II a un modelo semántico 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 3. Semántica aplicada a DATEX II 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 Evolución de DATEX II a un modelo semántico 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 Evolución de DATEX II a un modelo semántico • 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 4. Plataforma de publicación • 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 Evolución de DATEX II a un modelo semántico 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 4. Plataforma de publicación 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 Evolución de DATEX II a un modelo semántico 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 4. Plataforma de publicación 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 Evolución de DATEX II a un modelo semántico 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 4. Plataforma de publicación 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 Evolución de DATEX II a un modelo semántico 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 4. Plataforma de publicación 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 Evolución de DATEX II a un modelo semántico • 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 4. Plataforma de publicación 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 Evolución de DATEX II a un modelo semántico 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 4. Plataforma de publicación • 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 Evolución de DATEX II a un modelo semántico 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 Evolución de DATEX II a un modelo semántico 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 5. Resultados y discusión 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 Evolución de DATEX II a un modelo semántico 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 5. Resultados y discusión 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 Evolución de DATEX II a un modelo semántico 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 5. Resultados y discusión 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 Evolución de DATEX II a un modelo semántico 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 5. Resultados y discusión 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. Experimento 4 – Eficiencia de la consulta Q2 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 Evolución de DATEX II a un modelo semántico 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. Experimento 5 – Eficiencia de la consulta Q3 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 5. Resultados y discusión 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. Experimento 6 – Eficiencia de la consulta Q4 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 Evolución de DATEX II a un modelo semántico 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 Figura 40: Eficiencia de la ejecución para la consulta Q4 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. Experimento 7 – Eficiencia de la consulta Q5 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 5. Resultados y discusión 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 Figura 41: Eficiencia de la ejecución para la consulta Q5 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. Experimento 8 – Eficiencia de la consulta Q6 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 Evolución de DATEX II a un modelo semántico 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 Figura 42: Eficiencia de la ejecución para la consulta Q6 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. Experimento 9 – Eficiencia de la consulta Q7 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 5. Resultados y discusión 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 Figura 43: Eficiencia de la ejecución para la consulta Q7 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 Evolución de DATEX II a un modelo semántico 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 5. Resultados y discusión 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 Evolución de DATEX II a un modelo semántico 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 5. Resultados y discusión 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 Evolución de DATEX II a un modelo semántico 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 Evolución de DATEX II a un modelo semántico 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 Evolución de DATEX II a un modelo semántico • 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 Evolución de DATEX II a un modelo semántico 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 Evolución de DATEX II a un modelo semántico 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 Evolución de DATEX II a un modelo semántico 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 Evolución de DATEX II a un modelo semántico 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 Evolución de DATEX II a un modelo semántico 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 Evolución de DATEX II a un modelo semántico 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 Evolución de DATEX II a un modelo semántico III.4 CONSULTA Q4: SITUACIONES POR TIPO Definición Listado de situaciones por tipo ENTRADA: Tipo de situación SALIDA: Listado básico de situaciones 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 SALIDA: Listado básico de situaciones 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 Evolución de DATEX II a un modelo semántico 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