D 2.1 Descripción semántica del contexto

De MorfeoWiki

PROFIT

Morfeo-EzWeb

Área Temática: 350405 Strategic Action on Open Source Software
FIT-340503-2007-02 EzWeb

Entregable:

D 2.1 Descripción semántica del contexto

Versión:	1.0
Fecha de preparación:	7 de Diciembre de 2007
Editores:	Luis Polo, Diego Berrueta, Emilio Rubiera, Sergio Fernández (Fundación CTIC)
Revisores:	Iván Pérez Domínguez, Susana Muñoz (IMDEA), Alberto Cuesta (ITI)

Tabla de contenidos

1 D 2.1.1 Estado de la ciencia y análisis de requerimientos de las técnicas semánticas de modelado de contexto
2 D 2.1.2 Conceptualización e implementación de la ontología de modelado del contexto
3 D 2.1.3 Mecanismos de transmisión del contexto a los servicios de back-end
4 Referencias

[editar]

D 2.1.1 Estado de la ciencia y análisis de requerimientos de las técnicas semánticas de modelado de contexto

[editar]

Introducción

Actualmente, la mayoría de las aplicaciones se comportan sin tener en cuenta quién es el usuario, dónde está, con qué dispositivo se está conectando, si el usuario está trabajando, está en casa, etc. El uso de información contextual permite diseñar y desarrollar sistemas que incorporen la capacidad de manejar y adaptarse a la información de los usuarios y sus respectivos entornos.

La investigación sobre el contexto y el desarrollo de aplicaciones sensibles al contexto ha experimentado un auge importante en los últimos años a causa del nuevo concepto de la Web 2.0, las técnicas de representación de la Web Semántica y el impacto tecnológico de los nuevos dispositivos móviles. Sin embargo, la información contextual todavía sigue sin explotarse en su totalidad por las herramientas actuales y uno de los futuros retos tecnológicos es encontrar modelos de contexto que puedan ser reaprovechables por distintas aplicaciones.

En el proyecto EzWeb, se pretende que la plataforma sea capaz de manejar información contextual. Este entregable realizará un estudio sobre las distintas aproximaciones que se han hecho a la idea de contexto. El objetivo será buscar una definición de contexto que encaje con la aproximación tecnológica de este proyecto y que nos

El entregable se distribuye de la siguiente forma, en la primera parte del entregable se presentarán unos casos de uso iniciales para ilustrar en qué sentido se pretende explotarla información del contexto del usuario. Posteriormente, se analizará el concepto de contexto desde tres perspectivas diferentes. En primer lugar, se incidirá en la relación entre el contexto y el perfil del usuario. En esta parte del entregable, también se presentarán ontologías para la definición del perfil del usuario, como los vocabularios FOAF y SIOC. En segundo lugar, se analizará la diferencia que existe entre situación y contexto, dos conceptos relacionados. En este punto se estudiarán además las técnicas de representación de conocimiento para el tratamiento formal de los contextos. Por último, se estudiará qué significa ser sensible al contexto y algunos proyectos e iniciativas relacionadas con esta temática en el campo de la Web Móvil.

Este documento tomará como punto de partida los entregables del proyecto PROFIT MyMobileWeb relacionados con el contexto, en concreto el entregable para la especificación del contexto de navegación^[1] y el entregable para la definición del contexto de usuario^[2].

[editar]

Aplicación del contexto al proyecto EzWeb

La Plataforma EzWeb dispondrá de una serie de mecanismos para la extracción de los datos que permitan construir el contexto del usuario. Estos mecanismos se desarrollarán en el entregable D.4.1 de este proyecto. Como se menciona en este documento, habrá dos tipos de mecanismos para la extracción de información sobre el contexto del usuario:

Técnicas explícitas: mediante un formulario, el usuario podrá declarar una parte de su perfil, como sus aficiones, lugar de residencia, etc. Estos datos pueden ser muy heterogéneos y no todas las aplicaciones tienen por qué compartir el mismo modelo de formulario. Es decir, cada aplicación puede requerir un conjunto de datos diferente.

Técnicas implícitas: habrá información (como el user_agent^[3]) que el usuario no necesite declarar. Será la propia plataforma quien adquiera estos datos de forma automática.

A continuación presentamos una serie de casos de uso que pueden servir de aproximación inicial para el uso del contexto del usuario en la plataforma EzWeb. Hemos distinguido tres tipos de caso de uso, atendiendo a qué componente de la plataforma utilizará el contexto.

[editar]

Caso de uso 1 (Uso de información contextual por la plataforma EzWeb)

Este caso de uso ilustra la forma en cómo la plataforma EzWeb puede sacar partido de la información contenida en el contexto y explotarla a la hora de mejorar la experiencia de usuario y la personalización de la presentación de los contenidos.

César es un consultor de alto nivel para una empresa multinacional y su trabajo le exige viajar constantemente. César tiene actualmente 52 años y empieza a tener problemas de presbicia, lo que le obliga a utilizar gafas para leer los contenidos de una pantalla y a no poder trabajar constantemente delante de la misma.

César utiliza la plataforma EzWeb para su trabajo diario y para su entorno personal en sus desplazamientos fuera de casa. En la plataforma ha seleccionado una serie de gadgets que le permiten gestionar cómodamente su entorno laboral: su correo, su agenda personal, servicios de comunicación de mensajería instantánea y un servicio de callejero de ciudades europeas. Por otro lado, César ha configurado en la plataforma EzWeb un entorno personal independiente al dedicado a su trabajo. En este nuevo entorno, la mayor parte de los gadgets que utiliza César son servicios de sindicación de noticias mediante RSS y algún blog con contenidos específicos. Además ha añadido un gadget que ofrece información metereológica de los sitios a los que viaja. Por último hay que señalar que César no viaja siempre con su ordenador portátil, y utiliza en desplazamientos cortos un PDA con conexión WiFi.

Por tanto, la plataforma ha de ser contextualmente sensible y ha de poder utilizar contexto extraído mediante los mecanismos definidos en el entregable D.4.1 en tres cuestiones:

Terminal de acceso a la plataforma EzWeb. La plataforma debe ser capaz de detectar a través de qué dispositivo está accediendo el usuario, de manera que pueda personalizar la presentación de la plataforma y adecuarla a las posibilidades de cada dispositivo en cuestión. En este sentido, no sólo es importante determinar el tipo de dispositivo con el que se conecta el usuario, si no si el terminal es público o no para poder establecer políticas de seguridad particulares.
Hay que señalar, sin embargo, que EzWeb no es una plataforma para la movilización de aplicaciones y servicios. Aunque por ahora entendamos el contexto de una forma amplia, incluyendo tanto el usuario, como el terminal de acceso, etc., lo más conveniente es separar estos aspectos como se ha hecho en el proyecto MyMobileWeb Tractor y distinguir entre el contexto del usuario y el contexto de navegación. En esta línea de trabajo, sería conveniente revisar la investigación realizada en el proyecto mencionado, seguir la evolución del actual proyecto MyMobileWeb Celtic y estudiar las formas de conectar las dos plataformas.
Habilidades personales. La plataforma EzWeb debe ser sensible al perfil para adecuar los contenidos y gadgets, haciéndolos accesibles a cualquier tipo de usuario. Esta adaptación de la plataforma se realizará teniendo en cuenta aspectos tan dispares como variedades cromáticas, lay-outs adaptables a diferentes tamaños evitando el solapamiento visual de componentes, eliminación de barreras cognitivas como pueden ser textos móviles, etc.
Modos o configuraciones personales del usuario. La plataforma debe proporcionar un mecanismo para que el usuario pueda definir distintas configuraciones de su entorno personal teniendo en cuenta diferentes situaciones en las que se pueda encontrar. Por ejemplo, en el caso anterior César había definido dos modos o configuraciones, una para sus posibles situaciones laborales y otro para sus asuntos personales. El cambio de modo de la plataforma puede ser manual, bajo demanda del usuario, o automático, mediante la incorporación de nueva información al contexto localizando al usuario en una determinada situación o localización.

[editar]

Caso de uso 2 (Uso de información contextual por las aplicaciones mashup)

Este caso de uso presenta la forma en cómo las distintas aplicaciones dentro de la plataforma EzWeb pueden explotar la información sobre el contexto del usuario.

César, como ya hemos comentado en el Caso de Uso 1, ha definido dos configuraciones de su entorno EzWeb diferentes: el modo trabajo y el modo personal. Además César ha proporcionado información sobre su perfil a la plataforma, de forma que estos datos pueden ser reaprovechados por las aplicaciones de su entorno. En su modo trabajo, César utiliza un gadget para la gestión de sus contactos y de su agenda diaria: reuniones, notas y tareas. Esta aplicación le permite organizar su actividad personal, introducir nuevos eventos, añadir nuevos contactos y modificar y eliminar ambos. César ha introducido recientemente una reunión de trabajo en Berlín para la próxima semana. Por otro lado, César ha configurado el gadget callejero de su entorno para que sea sensible a su agenda: la visualización del callejero se modifica diariamente en base a dos parámetros, la localización de la actividad y la fecha/hora de la actividad. El día de la reunión, César accede a su entorno EzWeb y el gadget de callejero le sitúa en el mapa la localización de la reunión y la localización del hotel en el que se hospeda.

Por otro lado, César utiliza diariamente su aplicación de mensajería instantánea. Así como César ha sincronizado su agenda con su callejero, también ha hecho lo propio con sus contactos de agenda y su cliente para mensajería. César comparte la organización de su red social particular (compañeros de trabajo, clientes, expertos en materias, empresas proveedoras de servicios) entre su agenda y su cliente de mensajería favorito. Además, César utiliza la mensajería instantánea también para su vida particular: mantener el contacto con su familia cuando se desplaza y, sobre todo, con su hermano, que trabaja para IBM en Boston. El cliente de mensajería contextualiza la situación en la que está César, así mientras el modo trabajo está activo, sus contactos familiares están bloqueados de manera automática y, por contra, a partir de cierta hora se activa su modo personal de manera que sus contactos de trabajo no pueden molestarlo.

La plataforma EzWeb tiene que ser capaz de:

Proporcionar los mecanismos de persistencia para la información del perfil del usuario. La definición de las políticas de almacenamiento de estos datos sobre el usuario corresponderán en último término a los desarrollos de las distintas aplicaciones en la plataforma EzWeb.

Utilizar la información del contexto de forma que pueda ser reaprovechada por las distintas aplicaciones y por la propia plataforma. Es decir, la plataforma proveerá un API para que las aplicaciones puedan trabajar con la información del contexto. Esto garantiza cierta interoperabilidad entre las aplicaciones desarrolladas en EzWeb ya que tendrán acceso al catálogo de recursos de la plataforma y a un modelo de datos uniforme para el tratamiento del contexto del usuario. Además, los mashups de EzWeb serán capaces de exportar la información en un formato semántico, como RDF, de manera que puedan añadir, modificar o eliminar recursos del contexto o del catálogo. Por otro lado, la información del perfil del usuario puede utilizarse para mejorar la experiencia de usuario para completar formularios web, similar a la aproximación realizada en MyMobileWeb^[4]. De esta forma, la información del perfil del usuario podrá ser utilizada, a través de la plataforma, para suministrar información a terceros.
Proporcionar los mecanismos al usuario para que pueda editar su propia política de preferencias sobre la plataforma, contenidos, etc.

[editar]

Caso de uso 3 (Uso de información contextual para recuperar recursos del Catálogo de EzWeb)

Este caso de uso ilustra cómo la información del contexto del usuario se puede utilizar para mejorar la búsqueda de recursos del marketplace de la plataforma EzWeb. Este caso de uso utilizará técnicas de descubrimiento de recursos en base a la semántica del usuario que se desarrollarán e integrarán con la plataforma en el entregable D.4.1 de este proyecto, en las que habrá que estudiar técnicas de matchmaking^[5] semántico utilizadas en descubrimiento automático de servicios, comercio electrónico o encaje de perfiles.

César está preparando su viaje a Berlín de la próxima semana y necesita obtener información acerca de una serie de cuestiones, por ejemplo, dónde comer y cómo llegar desde el hotel que le ha reservado su agencia de viajes hasta su destino a las afueras de la ciudad. César utiliza el gadget de búsqueda del marketplace de recursos que proporciona la plataforma EzWeb para buscar servicios en la ciudad que va a visitar. Este gadget utiliza la información sobre las preferencias de César, que obtiene de su perfil. En concreto, César es vegetariano y prefiere viajar en tren, en vez de autobús u otro servicio público de transporte, como los taxis. El sistema de búsqueda tiene en cuenta estas preferencias y sugiere a César una lista de servicios para cada una de estas actividades.

Además a César le gusta estar informado de la actualidad de los sitios que visita, sobre todo de la actualidad deportiva y, en especial, del fútbol. Por eso, utiliza de nuevo el gadget de búsqueda de EzWeb para buscar contenidos sobre eventos deportivos locales en Berlín de acuerdo a las preferencias definidas anteriormente.

[editar]

Contexto y perfil de usuario

En un primer momento, la información que existía en la Web era estática, con contenidos con pocas actualizaciones y sin interacción con los usuarios. Es decir, era una Web independiente de los gustos, preferencias o situaciones. Los usuarios navegaban por la red saltando de una página a otra siguiendo los hiperenlaces. Sin embargo, en los últimos años la Web se ha ido transformando hacia un entorno abierto y dinámico surgiendo el concepto acuñado por Tim O'Reilly de Web 2.0^[6]. El cambio de paradigma no sólo viene propiciado por una evolución tecnológica con la introducción de nuevas herramientas como AJAX, servicios REST, sindicación de contenidos RSS o XUL. El desarrollo tecnológico viene de la mano de una demanda cada vez más creciente en la Web: la personalización de los contenidos.

Los usuarios tienen a su disposición nuevos servicios como son los blogs, wikis, las redes sociales que mejoran su presencia y la participación en la Web y les permiten además crear contenidos propios, como el caso de Flickr o youtube, compartirlos mediante etiquetas en portales verticales como LastFm o Tagzania o herramientas horizontales como es el caso de del.icio.us.

Los portales web también han necesitado adecuarse a esta demanda de los usuarios. Actualmente un gran número de portales requieren información del usuario para personalizar sus servicios y adaptarse a sus preferencias, mejorar su experiencia de usuario, mostrar sugerencias, etc. En este contexto, la información sobre el perfil del usuario es muy valiosa para los proveedores de servicios, ya que les permite individualizar la respuesta del servicio, realizar marketing y estudios de mercado, mostrar publicidad dirigida, sugerencias personalizadas de productos (supuestamente con un índice de impacto mayor, véase el caso de Amazon)... El grado de personalización del servicio dependerá de los recursos, del tipo de negocio, del tipo de cliente y de otra serie de factores. En cualquier caso, la personalización ayuda a establecer una mejor relación entre el proveedor de servicios y el usuario/cliente. La aspiración es la satisfacción máxima de los intereses del usuario. La personalización en la Web viene a ser similar a la compra de un coche: una vez que ya hemos decidido el modelo, queremos tener la posibilidad de seleccionar el color, el tipo de motor, gasolina o diesel, equipamiento extra, etc.

El contexto del usuario es el mecanismo para la captura y descripción de toda la información asociada al usuario que pueden utilizar las distintas aplicaciones para personalizar su respuesta o adecuar su interacción a sus intereses y preferencias. Evidentemente, las posibles situaciones en las que la información del usuario es valiosa son muchas y muy divergentes, desde portales que piden la declaración explícita de un perfil como eBay o InfoJobs, formularios on-line para la realización de trámites administrativos, suscripción a canales, o para sugerencias de publicidad, como es el caso de Google^[7] o GMail.

[editar]

Vocabulario FOAF

El vocabulario FOAF^[8] es el acrónimo de friend of a friend. Básicamente, FOAF es un vocabulario (conjunto de conceptos y propiedades) expresado en RDF que permite describir personas y relaciones entre ellas a partir de la propiedad, foaf:knows. Esta propiedad expresa conocimiento recíproco entre dos personas (aunque la reciprocidad no tenga porqué reflejarse obligatoriamente en un fichero FOAF). El grado de conocimiento de otra persona no está definido en la propiedad foaf:knows, ya que se puede utilizar para representar relaciones precisas y bien definidas entre dos personas (amistad, compañeros de trabajo, etc) o relaciones vagas entre dos personas. FOAF proporciona otra serie de conceptos para la descripción de entidades como proyectos, organizaciones o grupos de personas. El uso de FOAF está ampliamente extendido en la Web y lo utilizan alrededor de un millón y medio de personas (esta medida es aproximada y se calcula que su uso sea mayor).

Especificación gráfica de la ontología FOAF

En el entregable entregable D.3.2.2 para la definición del contexto de usuario del proyecto MyMobileWeb, se estudian posibles extensiones del vocabulario FOAF mediante otros vocabularios RDF. Estas extensiones permiten cubrir información personal del perfil del usuario como habilidades idiomáticas, preferencias gastronómicas o el curriculum vitae. Habrá que tener en cuenta estas posibles extensiones de FOAF para la construcción del modelo de contexto en EzWeb, ya que podrían ser necesarias para implementaciones particulares que requiriesen más información del usuario.

[editar]

Vocabulario SIOC

El vocabulario SIOC^[9] es el acrónimo de Semantically-Interlinked Online Communities. El vocabulario SIOC es un vocabulario RDF que permite describir formalmente comunidades on-line: listas de correo, wikis, weblogs, etc. Este tipo de foros nacen en torno a un sitio web para discutir y compartir información relevante sobre una determinada temática o una serie de tópicos, con lo que al final se llegan a formar verdaderas comunidades en torno a unos intereses comunes.

Hasta el momento, la mayor parte de las comunidades on-line no están conectadas. Los mismos asuntos se discuten en diferentes foros o listas de correo sin que sus usuarios sean conscientes de ello y sin se pueda compartir información o expresar relaciones que vinculen unos foros con otros. El objetivo de SIOC^[10] es superar esta barrera y ser capaces de interconectar estas comunidades virtuales construyendo en la Web una auténtica red social de miembros de estas comunidades.

Conceptos principales de SIOC

El vocabulario SIOC es especialmente relevante para EzWeb. No es difícil pensar que en la plataforma se desarrollen clientes de SIOC para la gestión y visualización de foros o listas de correo. SIOC además completaría la descripción del perfil del usuario y proporcionaría herramientas para el problema de la identidad en la Web. SIOC, por ejemplo, define la clase sioc:User que permite modelar las cuentas de usuario que tiene registradas cada persona y a su vez sioc:User se puede relacionar con un foaf:Person mediante la propiedad sioc:account_of. Si EzWeb utiliza FOAF para representar parte de la información del perfil de usuario, se pueden utilizar datos del perfil dentro de cada uno de los contextos en los que participan los sioc:User asociados a ese perfil. En el entregable D.2.3.1 se ha realizado una aproximación de cómo se puede utilizar la clase sioc:User para el modelo formal de la folksonomía.

[editar]

Extensiones e integración con otros vocabularios

La tecnología de la Web Semántica, y más concretamente el lenguaje RDF, permite combinar distintos vocabularios entre sí (véase el entregable D.2.1.2.). De esta forma, se pueden aprovechar diferentes vocabularios como son Dublin Core, SKOS-Core, FOAF o SIOC. Estas combinaciones de vocabularios ya están siendo estudiadas por los propios proyectos de FOAF y SIOC para mejorar la interoperabilidad entre aplicaciones y facilitar el intercambio de información.

Integración de los vocabularios RDF en el proyecto SIOC

Las buenas prácticas para la publicación de información en RDF utilizando diferentes vocabularios están siendo estudidads en el proyecto Linking Open Data^[11]. Esta iniciativa promovida por el grupo W3C Semantic Web Education and Outreach (SWEO) tiene como objetivo proporcionar los mecanismos generales para extender la Web mediante, en primer lugar, la publicación de datos comunes provenientes de fuentes de información públicas, como la DBPedia^[12] ; en segundo lugar, el uso del lenguaje RDF para la definición de los recursos y la construcción de los enlaces entre los recursos web relacionados; y, en tercer lugar, el uso de tecnologías existentes como los identificadores URIs y el protocolo HTTP. En Agosto del 2007, los datos publicados ascendían a más de dos billones de tripletas RDF relacionadas por más de 3 millones de enlaces RDF^[13].

Estas buenas prácticas para la publicación y combinación de información RDF son importantes para la construcción del módulo semántico de la plataforma, y deberán ser tenidas en cuenta para el desarrollo del catálogo de recursos y de la parte correspondiente al contexto que se corresponda con la definición del perfil del usuario.

[editar]

Contexto y situación

La cuestión del contexto aparece en varias áreas de la Inteligencia Artificial, como la representación de conocimiento, el procesamiento del lenguaje natural y la recuperación de información (IR). El concepto de contexto proviene de diferentes campos relacionados con la cognición: pragmática, semántica de las lenguas naturales, psicología, filosofía del lenguaje, etc. Hay un amplio consenso científico en considerar que la mayor parte de los procesos cognitivos son contextuales en el sentido de que dependen de la información del medio y del entorno. La intuición sobre la que se sustentan los estudios sobre el contexto es que el razonamiento, el ser capaces de inferir nuevo conocimiento a partir del conocimiento previamente definido mediante algún tipo de cálculo deductivo natural, suele realizarse sobre un subconjunto de la base de conocimiento. Es decir, a la hora de tomar decisiones, evaluar planes o realizar conjeturas no tenemos en cuenta todo lo que sabemos sobre el mundo, sino sólo una pequeña parte de él. Por ejemplo, es altamente improbable que mientras yo esté conduciendo en un día lluvioso, esté teniendo en cuenta a la hora de adelantar mi número de matrícula, cuál es la compañía con que tengo el seguro o quién es el presidente de la República Francesa. Toda esta información sencillamente no es relevante para esta situación y, por tanto, no se tiene en cuenta.

Desde luego, este tipo de consideraciones filosóficas o científicas sobre los procesos cognitivos y cómo trabaja la mente son irrelevantes para el proyecto EzWeb y por eso quedan fuera de este entregable. Sin embargo, sí se examinarán cuáles son los modelos de contexto estudiados en la teoría de representación de conocimiento por dos motivos:

Las teorías que se señalan a continuación tratan el contexto como un objeto matemático y, por tanto, proporcionan formalizaciones que pueden ser aprovechadas en el desarrollo del modelo de contexto de EzWeb.
Estas teorías ponen de manifiesto la diferencia que existe entre la idea situación y contexto. Es importante tener esta distinción en cuenta ya que la introducción de puntos de vista del usuario implica que es necesario distinguir entre descripciones objetivas (situación) del mundo y descripciones subjetivas (contexto).

Para EzWeb puede ser importante distinguir bien entre situación y contexto^[14] ya que ambos conceptos no son idénticos. Una situación es una descripción del mundo en un instante determinado de tiempo. Una situación recoge el estado del mundo tal cual, de forma objetiva. Sin embargo, un contexto no es una situación. Los contextos son teorías parciales del mundo que recogen una serie de asunciones y hechos desde un punto de vista concreto. En este sentido, una situación es independiente del agente que la representa mientras que los contextos son el conjunto de información relevante para un agente en una situación.

EzWeb, tal y como se ha presentado en los casos de uso descritos más arriba, puede hacer uso de esta distinción conceptual entre situación y contexto y aprovecharlo para su construcción del modelo del contexto en el entregable 2.1.2. Este modelo sólo se debería centrar en la caracterización de los contextos de los usuarios, es decir, en los aspectos relevantes de las diferentes situaciones del mundo real que permitan una configuración particular automática de su interfaz (gadgets disponibles y dependencias entre ellos) y el acceso a una determinada información del perfil del usuario que puede ser explotada por los diferentes gadgets que tenga activados. Desde el punto de vista del usuario, éste debe poder definir diferentes situaciones que la plataforma debe tener en cuenta, pero desde el punto de vista de la plataforma, la definición de estas situaciones tiene que obedecer a criterios de estricta relevancia para su aplicación, junto con posibles preferencias del usuario asociadas a esa situación, en el ámbito de Ezweb.

A continuación se presentan dos enfoques de interpretación del contexto:

El contexto_T es el conjunto de axiomas y hechos relevantes para la resolución de un problema : Teorías formales del contexto
El contexto_O es un concepto ontológico, un objeto social no-físico resultado de la reificación de contexto_T : Ontología de las Situations&Descriptions.

[editar]

Teorías formales del contexto

De acuerdo con McCarthy^[15], en la representación del sentido común no existe un contexto general en el que todos axiomas declarados se mantengan siempre. Un axioma siempre es dependiente de un contexto determinado, y siempre se puede presentar un nuevo contexto en el que este axioma falle. McCarthy formalizó esta idea de verdad relativa a un contexto mediante el predicado ist(p,c), que se interpreta como la proposición p es verdad en el contexto c.

Existen dos aproximaciones clásicas para la formalización de los contextos y su aplicación en diferentes entornos.

Teoría del contexto divide-y-vencerás

Esta teoría fue inicialmente formulada por McCarthy. Entiende el contexto como un mecanismo para dividir y particionar una teoría global sobre el mundo. En general una teoría de este tipo tiene los siguientes elementos:

Un lenguaje de representación L que permite representar los hechos que son verdad en un contexto c y tratarlos de forma independiente al resto de contextos.
Relaciones de jerarquía entre los propios contextos que permitan cambiar de un contexto a otro más general: lifting rules.
Relaciones laterales (o no jerárquicas) entre hechos de diferentes contextos.

Esta aproximación al contexto se utilizó para la construcción de la arquitectura de microteorías en CYC por Guha, y su desarrollo matemático ha sido continuado por Buvac en Propositional Logic of Context^[16].

Teoría del contexto compón-y-vencerás

Estas teorías presuponen que el conocimiento de un agente está compuesto de diferentes bloques de conocimiento local. Cada uno de estos bloques es en sí mismo una teoría completa sobre una parte reducida y acotada del mundo (dominio) desde un punto de vista particular, el punto de vista del agente. Cada de uno de estos bloques es un contexto y pueden ser: teorías de dominio (teorías sobre vehículos, la fabricación del acero, modelos de instituciones, etc.), instantáneas de una situación dinámica (el estado de una partida de ajedrez, una tarea llevada a cabo durante la ejecución de un plan, etc.), representación de una parcela del mundo (los objetos que hay en mi cuarto o los restaurantes de la ciudad de Boston) o creencias adscritas a otros agentes (lo que María cree que Juan está pensando).

Otra característica importante y que la distingue completamente de la aproximación divide-y-vencerás es que no existe una relación a priori entre contextos. Mientras que en el primer caso, cada uno de los contextos está visto como una rama de una teoría o descripción general del mundo, las técnicas de representación de conocimiento compón-y-vencerás entienden que las relaciones entre contextos se establecen entre iguales (P2P). De esta forma, la relación de jerarquía entre contextos es una posible relación más que se puede establecer, pero ni es obligatorio su uso ni está implícito en la propia construcción de la teoría.

Los sistemas basados en la estrategia de compón-y-vencerás utilizan formalizaciones basadas en Local Model Semantics (LMS)^[17]. En un sistema LMS no es necesario un lenguaje L de representación general, como en las formalizaciones anteriores. El lenguaje de representación es dependiente del contexto y refleja el compromiso ontológico en sus descripciones locales del mundo. Cada contexto c_i, es decir cada base de conocimietno, tiene asociado un lenguaje de representación L_i particular. Cada contexto c_i se asocia con una teoría T_i y un conjunto de fórmulas expresadas en L_i. La extensión de los predicados y los valores de verdad son dependientes del contexto c_i, ya que están definidos respecto al lenguaje y modelo de c_i.

Un sistema LMS tiene, por definición, las siguientes características:

El razonamiento es local, ya que siempre ocurre dentro de un contexto. No hay ningún espacio que contenga todo el conocimiento de un agente o, en otras palabras, que abarque todos los contextos. El hecho de que cada contexto utilice además su propio lenguaje formal significa que cada contexto c_i pueda tener sus propias reglas de cálculo y que los motores de inferencia sean distintos según qué contexto.
Los contextos son compatibles. Un sistema LMS permite expresar restricciones de compatibilidad entre diferentes contextos. Esta restricciones se definen como reglas que relacionan cada una de las teorías T_i.

En ^[18] se aplica la noción de sistema LMS al lenguaje OWL. El objetivo de este trabajo es conjugar los aspectos importantes de dos herramientas para la representación de conocimiento: las ontologías y los contextos. Por una lado, las ontologías son modelos compartidos de un dominio por una serie de entidades participantes. Por otro, los contextos son modelos locales de dominio, en el sentido de que son puntos de vista particulares. Los autores han desarrollado un lenguaje, Context-OWL (C-OWL), que extendiendo la sintaxis y semántica de OWL permite trabajar con ontologías contextualizadas. El objetivo es poder mantener el conocimiento de cada ontología de forma local (como un contexto) y mediante una serie de reglas (bridge rules) definir compatibilidad entre conceptos de diferentes ontologías. Estas reglas permiten expresar diferentes mappings entre conceptos: equivalencia, subsunción e intersección. El objetivo de C-OWL es poder alinar diferentes ontologías en un mismo espacio conceptual interpretando ontologías en OWL dentro de un sistema LMS.

[editar]

Ontología de las Situations&Descriptions

La aproximación de la ontología Situations&Descriptions ^[19] al contexto es complementaria al desarrollo de la ontología de alto nivel DOLCE (Descriptive Ontology for Linguistic and Cognitive Engineering). Situations&Descriptions reifica cualquier entidad imaginable, desde predicados, sistemas, teorías o modelos, técnicas, etc. Su propósito fundamental es permitir una caracterización asequible de los denominados objetos sociales y muy especialmente lo que se conoce como descripciones (conceptualizaciones de entidades complejas como métodos, planes, diseños de artefactos, etc.).

Técnicamente es un módulo consistente en una ontología que contempla varios conceptos imprescindibles y una serie de reglas para la reificación^[20] de estados de cosas, situaciones, contextos... La diferencia entre las Situations&Descriptions y las teorías formales examinadas anteriormente, es que, mientras que en el caso anterior, los contextos eran el conjunto de fórmulas y sentencias relevantes para un acto concreto de razonamiento, en el caso de las Situations&Descriptions, los contextos son objetos de primer orden que permiten la integración de conceptos en una ontología involucrados en la definición de un estado de cosas o situación. Por ejemplo, en el caso de una situación como un accidente de tráfico, habrá un estado de cosas objetivo sobre los participantes en esa situación, cuándo ocurrió, los coches involucrados, etc. Sin embargo, si preguntamos a cada uno de los testigos, su testimonio sobre el accidente variará de uno a otro sensiblemente. Cada uno de estos testimonios constituye una descripción, una estructura que emerge de una situación y permite describirla (pero siempre bajo un punto de vista específico: si cambia el punto de vista, cambia la estructura y la descripción ya no es la misma).

La ontología Situations&Descriptions y sus mecanismos de integración con cualquier ontología pueden ser de gran utilidad a la hora de aplicar el contexto a EzWeb sin comprometer el propio modelo de contexto con una ontología o serie de ontologías específicas.

[editar]

Contexto y aplicaciones sensibles al contexto

Un sistema sensible al contexto es un sistema que es capaz de extraer información del entorno del usuario, representar y almacenar esta información y adaptar su funcionalidad al contexto actual de uso. La información relativa al contexto del usuario puede ayudar a mejorar la comunicación hombre-máquina: adaptar los contenidos a las habilidades personales de los usuarios, al tipo de dispositivo, tener en cuenta factores de contexto como es la localización del usuario y los recursos que tiene cercanos, sacar provecho de información temporal y espacial para el cálculo de rutas en entornos controlados, etc.

Básicamente, un sistema es sensible al contexto si sigue la siguiente definición:

Un sistema es sensible al contexto si utiliza el contexto para proporcionar información y/o servicios relevantes para el usuario, donde la relevancia depende de la actividad del usuario.^[21].

Cualquier tipo de información disponible en el momento de una interacción y que se tenga en cuenta para un determinado proceso o respuesta puede ser entendida como información contextual. Como señalan Dey Abowd^[22] se pueden distinguir cuatro conjuntos de datos relevantes para la definición del contexto del usuario.

Identidad
Información espacial: localización, velocidad, orientación, etc.
Información temporal: fecha, hora del día, intervalos temporales, etc.
Información sobre el entorno: temperatura, nivel de luz o de ruido.

Las aplicaciones sensibles al contexto del usuario se han estudiado sobre todo en el campo de la Independencia de Dispositivo y de la Web Móvil^[23]. Existen grandes diferencias entre usuarios móviles y usuarios fijos, como son los diferentes tipos de contenido que manejan, las capacidades de los dispositivos que utilizan (pantallas pequeñas) y la situación en la cual el usuario recibe el contenido (por ejemplo, en el autobús). En el segundo caso, la Web Móvil es una iniciativa del W3C cuyos objetivos consisten en que el acceso a la información pueda realizarse desde cualquier lugar, en cualquier momento e independientemente del dispositivo utilizado a través de aplicaciones que se adapten dinámicamente a las necesidades del usuario, a las capacidades del dispositivo y a las condiciones del entorno. Esto se conoce como Delivery Context^[24]

Las aplicaciones sensibles al contexto tienen una serie de características comunes (y que casan con los propósitos de EzWeb):

La información y los servicios pueden presentarse al usuario de acuerdo con el contexto actual. Esto incluye la selección de información o servicios en base a diferentes criterios, por ejemplo, un criterio de localidad. En este caso un sistema sensible al contexto podría sugerir sólo restaurantes próximos a donde se encuentra el usuario.
Ejecución automática de un servicio en un determinado contexto. El sistema dispara acciones o realiza tareas de adaptación en base al contexto del usuario. En el primer caso, un sistema sensible al contexto podría activar el modo silencio del móvil si el usuario entra en una sala de reuniones. En el segundo, el interfaz de un dispositivo podría configurarse de forma diferente según la hora del día.
Los contextos pueden ser etiquetados para su posterior recuperación. Un usuario puede acceder a su colección de contextos y activarlos de forma voluntaria, si así lo desea.

[editar]

Context Toolkit

Véase el entregable D.2.1.5..

[editar]

AmbieSense

El proyecto AmbieSense (Ambient Intelligence Landscape) es un proyecto de investigación financiado por el V Programa Marco de la Comisión Europea. El objetivo de este proyecto es el desarrollo de tecnología para dispositivos móviles que permita proporcionar información relevante al usuario teniendo en cuenta el contexto en el que se encuentra éste. Los usuarios pueden además etiquetar los contextos, recuperarlos y establecer políticas de actuación para los mismo. Lo más destacable del proyecto en lo que respecta al contexto para la plataforma EzWeb, es el modelo conceptual y la definición del contexto, que de nuevo traza una separación entre lo que es contexto y lo que es situación.

Un contexto describe aspectos de una situación vista desde el particular punto de vista de un actor. Un actor puede ser, en el sentido amplio de la palabra, una persona, una cosa, materia o un organismo. En este sentido, el contexto se define como algo separado de la situación en sí misma. Un contexto en AmbieSense es una representación dentro de una máquina. Representa aspectos de una situación en el mundo real. ^[25].

La información relativa al contexto se expresa mediante pares atributo-valor y se divide en cinco tipos de contexto complementarios:

Contexto del entorno (Environment Context): Esta parte del contexto captura las entidades cercanas al usuario. Por entidades cercanas se entiende desde objetos o personas que estén físicamente en el mismo entorno que el usuario hasta la información a la que está accediendo el usuario en ese momento (por ejemplo, una película o un documento pdf).
Contexto personal (Personal Context): El contexto personal describe en el ámbito del proyecto AmbieSense atributos y propiedades de los usuarios. Aquí la información puede tratar propiedades físicas de las personas como la temperatura, el peso, el nivel de glucosa o la dilatación de las pupilas. El proyecto contempla un perfil más amplio del usuario para poder expresar el grado de experto en alguna materia, preferencias de los usuarios acerca de contenidos, etc.
Contexto de actuación (Task Context): Este contexto describe qué están haciendo los actores del contexto del usuario. Se describen objetivos, tareas, acciones, eventos y actividades. También incluye todas las personas que están envueltas en las distintas situaciones. Por ejemplo, en el caso de un viaje en coche, este contexto incluirá la actividad de viajar, la posición de los viajeros en el coche y quién es el conductor.
Contexto social (Social Context): Se describen los aspectos sociales del contexto de usuario. Este contexto contiene información sobre la red social del usuario: amigos, compañeros de trabajos, familia, etc. Un aspecto importante del contexto social es que permite describir el rol del usuario en el contexto. De forma que para un contexto determinado podemos asociarle un área geográfica, un conjunto de roles y de actividades asociadas a esos roles.
Contexto espacio-temporal (Spatio-temporal Context): Este contexto describe aspectos del usuario relacionados con la extensión espacial y temporal del contexto de usuario: tiempo, localización, dirección o velocidad.

[editar]

Evaluación

En este estado del arte se han examinado tres aproximaciones diferentes a la idea de contexto: 1) la relación entre el contexto y el perfil del usuario, 2) cuáles son las formalizaciones lógicas usuales del contexto y 3) qué significa ser sensible al contexto del usuario. En posteriores revisiones del documento se entrará en detalle en cada de ellas y se valorará más explícitamente qué elementos son reaprovechables para el contexto en EzWeb.

Por ahora, podemos extraer las siguientes conclusiones:

La definición del perfil de usuario es fundamental para la construcción del contexto en EzWeb. El usuario y su entorno son las piezas clave que articulan el resto de información: localización del usuario, situación en la que se encuentra, preferencias sobre contenidos o servicios, habilidades personales que pueden influir en cuestiones de presentación, etc. Se reaprovecharán vocabularios como FOAF, SIOC, DOAP, Dublin Core y se seguirá la evolución de iniciativas como Open Linking Data. El uso de RDF como modelo de datos común de estos vocabularios permitirá combinarlos y fusionar información provenientes de fuentes heterogéneas.
Los proyectos para el desarrollo de aplicaciones y sistemas sensibles al contexto en el campo de la Web Móvil son la base para identificar los elementos necesarios que deben articular los contextos en EzWeb. La mayor parte de sus modelos no están trabajados formalmente, pero recogen intuiciones sobre cuáles son los conceptos llave en la definición del usuario y su entorno, como la localización o la identidad.
El contexto y su tratamiento formal es completamente necesario en EzWeb.
1. Las teorías formales del contexto no son de gran ayuda a la hora de interpretar el contexto en EzWeb. Sin embargo, la idea de verdades relativas a contextos es importante a la hora de considerar las políticas de preferencias de los usuarios. Las preferencias de los usuarios engloban las configuración de la plataforma, cómo espera un usuario que se comporte la plataforma de acuerdo con sus necesidades o la selección de gadgets. Este tipo de conocimiento, al igual que en las teorías formales de McCarthy, Buvac o Giunchiglia es relativo a los diferentes contextos de usuario. Si un usuario está en una situación de trabajo puede querer que EzWeb mantenga inactivo el sonido en la reproducción de vídeos.
2. El tratamiento del contexto como una description (véase sección 1.4.1) es útil a la hora de articular un módulo semántico para el contexto en EzWeb. Por un lado, podemos tratar ontológicamente el contexto como la reificación de un estado de cosas o situación en la que se encuentra el usuario y la plataforma, interpretándolo como una description. El uso de la ontología de las Situations&Descriptions junto con la ontología DOLCE es una herramienta metodológica de gran valor. Por otro lado, EzWeb puede copiar el mecanismo que utiliza la ontología de las Situations&Descriptions para extender cualquier ontología en la implementación del contexto en la plataforma. De esta forma, independientemente de los vocabularios, ontologías o modelos utilizados para la descripción del catálogo de recursos, el perfil del usuario o las anotaciones de los recursos en EzWeb, el contexto se puede acoplar extendiendo la ontología original con nuevos conceptos, propiedades y axiomas que permiten el tratamiento contextual automático de los recursos por parte de EzWeb.

[editar]

D 2.1.2 Conceptualización e implementación de la ontología de modelado del contexto

[editar]

Introducción

En este entregable se formalizará el modelo del contexto para el proyecto EzWeb. Para la construcción del modelo conceptual del contexto se utilizará el análisis sobre el estado del arte realizado por el entregable D.2.1.1. Se incidirá especialmente en la definición clara y precisa de los conceptos situación, contexto y perfil del usuario. Se reaprovecharán vocabularios y ontologías que actualmente están en uso en la Web Semántica, como puede ser el caso de SIOC, de forma que el contexto en EzWeb pueda ser compatible con otras plataformas o proyectos.

[editar]

Modelo conceptual del Contexto en EzWeb

En esta sección se presentará el modelo conceptual para el contexto en EzWeb, que se deberá integrar con el resto de los componentes semánticos de la plataforma. La arquitectura semántica de EzWeb proporciona una serie de mecanismos para la descripción de recursos y el contexto. Esta información la aprovechan distintos componentes de la plataforma, desde componentes de presentación, el sistema de búsqueda de recursos o los propios gadgets. Básicamente tenemos tres tipos de entidades relevantes para construir la arquitectura semántica de la plataforma: los recursos del catálogo, el contexto y las anotaciones (folksonomías). Estas tres entidades están interrelacionadas entre sí. Los recursos se pueden describir de forma complementaria mediante:

Descripciones formales de los recursos del catálogo (o marketplace): gadgets, servicios y contenidos, utilizando modelos conceptuales de dominio, ya sean vocabularios controlados o, en el caso más complejo, ontologías. Estas descripciones organizarán los recursos del marketplace clasificándolos de acuerdo a una serie de criterios definidos formalmente: por ejemplo, saber si un gadget es de tipo agenda (AgendaGadget) o un mapa (MapGadget). En la medida de lo posible, el modelo semántico del catálogo de recursos reutilizará ontologías y vocabularios ya conocidos que permitan la integración de distintas fuentes de información.
Anotaciones informales (folksonomías) de los recursos creados por la comunidad de EzWeb. Como se explica en el entregable 2.3.1, el modelo formal de folksonomía integra los conceptos de ezweb:Annotation y ezweb:Tag con los usuarios que etiquetan y los recursos que son etiquetados.

Respecto al contexto en EzWeb, la propuesta inicial que se va a considerar en este entregable es la construcción de una ontología que pueda ser reutilizable en distintas arquitecturas semánticas. No es deseable que este módulo para la definición del contexto tenga dependencias con modelos u ontologías concretas para la descripción de los recursos, o de los propios usuarios. Por ejemplo, si EzWeb se despliega en un entorno empresarial, no es obligatorio el uso del concepto foaf:Person para la identificación de las personas. Cada caso de aplicación concreto puede requerir nuevos vocabularios y ontologías, reutilizados o creados ex novo, y el componente de contexto de EzWeb debe ser lo suficientemente flexible para adaptarse a nuevas estructuras semánticas. El objetivo es proporcionar una infraestructura lo suficientemente genérica que dada una ontología cualquiera O, se pueda extender con el componente para el modelado del contexto de EzWeb.

El mecanismo que se sugiere consiste en añadir a la ontología O como mínimo dos nuevos predicados: UserContext y EzContext, y una relación entre ambos d-uses, propiedad definida en la ontología Situations&Descriptions. Esta transformación de O inducida por el componente de contexto requerirá la definición de una serie de operaciones (OP_ctxt) para la instanciación del contexto en O: $O \ \cup \ (Ctxt + OP_{ctxt})\longrightarrow \ O^+$ . La ontología enriquecida con el contexto ( $O +$ ) contendrá además de la ontología inicial (O), la información de contexto (Ctxt) y las operaciones necesarias para el manejo de esta nueva información (OP_ctxt).

[editar]

UserContext

Este concepto recoge los contextos de los usuarios. Los contextos de los usuarios pueden ser dos tipos:

Situaciones del mundo real en las que se encuentra el usuario. En este caso, el contexto es la formalización de la información relevante de la situación que permite a EzWeb aplicar algún tipo de funcionalidad de acuerdo con las preferencias de los usuarios. En este caso, aplicamos la distinción estudiada en el entregable D2.1.1 sobre situación y contexto. Un típico ejemplo de lo que representa aquí un contexto es una situación de trabajo. Un usuario podrá definir no la situación real de su trabajo en sí, sino la información relevante para que la plataforma puede adaptarse a este contexto: qué gadgets deben estar activados, qué tipo de información como noticias o mails se debe filtrar para su presentación, bloqueo de contactos, etc.
Definición de intervalos temporales en los que las preferencias de los usuarios varían. Un usuario de EzWeb no desea ver los mismos contenidos en su gadget lector de RSS por la mañana que en otro momento del día. La selección y adaptación de contenidos de la plataforma se realiza en estos casos atendiendo a diferentes criterios y preferencias del usuario establecidos para diferentes partes del día.

En una primera aproximación, la implementación del modelo conceptual del contexto se realizará utilizando una ontología y posiblemente los formalismos de la lógica descriptiva. Este lenguaje permite la descripción de conceptos mediante las relaciones que tienen con otros conceptos del dominio. En el caso de EzWeb, posibles definiciones de diferentes contextos de los usuarios podrían ser las siguientes (una de las cuestiones a tener en cuenta para el futuro es la expresividad de la lógica que se escoja):

Las situaciones en coche: $CarContext \sqsubseteq UserContext \ \sqcap \ (\exists location. Car)$ .
Las situaciones de trabajo: $BusinessContext \ \sqsubseteq UserContext \ \sqcap \ (\exists location. BusinessPlace \ \sqcup \ (\exists location. PublicPlace \ \sqcap \ \exists time.OfficeHour))$ .

La descripción completa del UserContext puede requerir diferentes conceptos según sea el caso de aplicación. Sin embargo, podemos identificar una serie de conceptos generales que deben ser tenidos en cuenta explícitamente en nuestro modelo:

Usuario: quién es el usuario y qué información tenemos sobre él: curriculum vitae, habilidades personales, nombres y apellidos, etc.
Actividad o tarea del usuario: qué está haciendo en la situación x. Las actividades de los usuarios también se pueden inferir a partir de los posibles contextos o viceversa.
Perfil del usuario: cuál es el perfil del usuario en la situación x. Los perfiles también pueden determinar el conjunto de posibles actividades en base al tipo de contexto de usuario.
Preferencias e intereses de los usuarios: las preferencias de los usuarios se aplican tanto al tipo de configuración o configuraciones que un usuario quiere establecer sobre su entorno EzWeb, como a preferencias o intereses sobre determinados contenidos, por ejemplo, si prefiere comida tailandesa a comida japonesa. Preferencias de este último estilo deberán utilizarse para la búsqueda de recursos en base a los perfiles de los usuarios.

[editar]

EzContext

Este concepto recoge el contexto de la plataforma: las posibles configuraciones del entorno EzWeb definidos por el propio usuario. Cada uno de estos contextos se define en base a los gadgets activados en el interfaz de usuario, a cuáles son las dependencias (si existen) entre los gadgets (por ejemplo, si el gadget Mapa es compatible con la agenda del usuario), qué contenidos están accesibles al usuario y al resto de los gadgets, etc. Estos contextos se pueden relacionar con otros contextos, modificándolos o extendiéndolos.

A continuación, se ilustra una primera aproximación al contexto en EzWeb. Los conceptos y las relaciones son provisionales y están sujetas a discusión (no es necesario, por ejemplo, interpretar obligatoriamente los nodos como clases). La propiedad d-uses (description-uses) relaciona el contexto del usuario (UserContext) y el de la plataforma (EzWeb). Se utilizará en un modelo más avanzado del contexto para articular las dependencias de los entornos de la plataforma y los gadgets que los componen en base a las preferencias y al contexto del usuario.

Modelo conceptual del contexto en EzWeb

[editar]

Políticas de preferencias e intereses de usuario

Los conceptos UserContext y EzContext se relacionan entre sí. Los contextos de los usuarios pueden implicar diferentes configuraciones de la plataforma, el acceso a diferentes contenidos o la activación de nuevos gadgets. Por otro lado además, la relación entre UserContext y EzContext no es una relación de uno a uno. Puede haber diferentes situaciones del usuario pero que la configuración de plataforma sea la misma. En EzWeb, el usuario podrá definir sus preferencias. Esta información y los datos relevantes de su contexto se utilizarán para adaptar dinámicamente su entorno personal a sus preferencias.

Volviendo al ejemplo del entregable D.2.1.1, imaginemos que César ha definido una serie de configuraciones de la plataforma (instancias de EzContext) . Por otro lado ha definido un conjunto de posibles situaciones de trabajo (UserContext), como ir en carretera, reunión, oficina. César quiere que EzWeb se adapte automáticamente a sus necesidades y por eso ha definido una serie de preferencias. Una de estas preferencias es la siguiente:

Preferencia 1: Si César está en una reunión de trabajo (context:BussinessMeeting) y la plataforma utiliza una configuración predeterminada (context:EzContext), entonces César quiere disponer automáticamente de un gadget para tomar notas durante la reunión (market:NotesGadget).

Este tipo de información, políticas de preferencias de los usuarios, no se pueden expresar en general con una lógica descriptiva. Sería necesario utilizar lógicas o lenguajes para la definición de sistemas de reglas. A continuación presentamos cómo se podría implementar la preferencia del ejemplo anterior construyendo una regla sobre el modelo RDF de la ontología del contexto. Utilizaremos en un primer lugar el motor de inferenciareglas Jena2

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>.
@prefix context: <http://ezweb.morfeo-project/ns/context#>.
@prefix market: <http://ezweb.morfeo-project/ns/marketplace#>.

[User_rule_01: (?usercontext rdf:type context:BussinessMeeting),
                   (?platformcontext rdf:type context:EzContext),
                   (?platformcontext context:d-uses ?usercontext),
                   (?gadget rdf:type market:NotesGadget)
                   ->
                   (?platformcontext context:d-uses ?gadget)]

Otra posibilidad sería utilizar el lenguaje de consultas para RDF, SPARQL^[26]. En ^[27] se describe cómo se pueden construir consultas SPARQL con el operador CONSTRUCT que simulen el comportamiento de reglas de producción simples sobre grafos RDF. Esta misma aproximación puede ser utilizada en EzWeb, en caso de que las políticas de los usuarios consten de reglas sencillas y fáciles de implementar:

PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX context: <http://ezweb.morfeo-project/ns/context#>
PREFIX market:  <http://ezweb.morfeo-project/ns/marketplace#>

CONSTRUCT { ?x context:d-uses ?gadget } 
WHERE {
        ?x rdf:type context:EzContext .
        ?y rdf:type context:BusinessMeeting .
        ?x context:d-uses ?y .
        ?gadget rdf:type market:NotesGadget .
      }

Por ahora es irrelevante cómo se llega a la información del gadget. Queda por definir la relación entre el contexto y el marketplace de recursos. El usuario tendrá definida su paleta: conjunto de gadgets preferidos, que hará que la ejecución de las reglas no se ejecute sobre todo el universo de recursos del catálogo, sino sobre el subconjunto utilizado por el usuario.

[editar]

Representación de conocimiento en la Web Semántica

El contexto es un componente más del módulo semántico de EzWeb. Por tanto, el lenguaje de representación utilizado debería estar acorde al resto de componentes semánticos de la plataforma. El lenguaje o lenguajes que se utilicen para la representación del contexto tienen que ser compatibles con la tecnología de la Web Semántica y más concretamente con RDF, el modelo de datos común para la representación de información semántica en la Web.

Una importante propiedad de la Web Semántica es que la información se define utilizando lenguajes formales para el procesamiento automático de las máquinas y la derivación de nuevo conocimiento a partir del conocimiento declarado y mediante reglas formales de deducción asociadas a estos lenguajes. Los lenguajes lógicos son estos lenguajes formales. Para la formalización del modelo conceptual del contexto se estudiarán diferentes alternativas de lenguajes basados en lógica para la expresión de conocimiento en la Web Semántica y se analizarán sus propiedades formales más sobresalientes, así como su grado de adopción por la industria o su estatus de estándar.

El modelo conceptual del contexto en EzWeb se basa en dos tipos de información

Conceptos y propiedades necesarias para la definición del contexto: por ejemplo, UserContext. La descripción formal de estos recursos se realizará utilizando un lenguaje web para la construcción de ontologías.
Las políticas de preferencias de los usuarios. Esta información se representará mediante un sistema de reglas que permita a los usuarios declarar el comportamiento que esperan de la plataforma en base a sus contextos.

[editar]

Lógica en la Web Semántica

Los lenguajes lógicos se utilizan para la representación de distinto tipo de conocimiento, en particular, ontologías y reglas. En esta sección analizaremos un conjunto de lenguajes lógicos que pueden ser utilizados para la representación de conocimiento en la Web Semántica. Estos lenguajes son potencialmente interesantes para la representación del contexto en EzWeb.

Lógica de primer orden es la base para todos los lenguajes que se estudiarán en esta sección del entregable. Semántica formal basada en interpretaciones: asunción de Mundo Abierto
Lógicas descriptivas son una familia de lenguajes que representan, en su mayoría, subconjuntos estrictos de la lógica de primer orden. Los lenguajes de esta familia permiten la definición de conceptos, jerarquías de conceptos, roles y restricciones sobre los roles (cardinalidad, transitividad, etc.). La lógica descriptiva básica es ALC (Attributive Language with Complement). Otra lógica interesante es DLP (Description Logic Programming), un subconjunto de la lógica descriptiva y la lógica Horn. Los lenguajes de la Web Semántica OWL Lite y OWL-DL están basados en las lógicas descriptivas SHIF y SHOIN, extensiones de la lógica básica ALC. También es interesante estudiar el lenguaje RDF(S)*, subconjunto de RDF(S)* y de OWL.

Programación Lógica está basada en la lógica Horn, un subconjunto de la lógica de primer orden, que permite escribir reglas de la forma "si A entonces B", aunque en el caso de la Programación Lógica su semántica formal no está basada en interpretaciones de primer orden: asunción de Mundo Cerrado.

F-Logic Programming es un subconjunto de la Frame Logic. Esta lógica es una extensión de la lógica de primer orden que permite un estilo de modelado orientado a objetos basado en frames. Frame Logic no aumenta el poder expresivo de la lógica de primer orden, pero tiene un estilo de modelado más conveniente e intuitivo. F-Logic Programming ha sido propuesto como la base para los lenguajes de ontologías en la Web Semántica.

[editar]

EzWeb y Resource Description Framework (RDF)

Ejemplo de una tripleta RDF

El Resource Description Framework (RDF)^[28] es el modelo de datos básico para la Web Semántica. Es un lenguaje lógico simple que permite especificar propiedades binarias y describir recursos a partir de éstas. RDF es el modelo de datos semántico que se utilizará como base para la construcción del componente semántico de la plataforma EzWeb y, por tanto, la implementación del contexto deberá buscar una solución compatible.

RDF está construido sobre una de las estructuras más simples para representar datos: un grafo dirigido etiquetado. Un grafo RDF es típicamente un conjunto de tripletas de la forma <Sujeto,Propiedad,Objeto> y cada una de estas tripletas es una aserción que expresa que un recurso (una entidad en la Web Semántica) está relacionado con otra entidad o con un valor a través de una propiedad. Utilizando la terminología RDF, los recursos y propiedades se identifican mediante URIs (Uniform Resource Identifiers).

En un grafo RDF, los nodos siempre se referencian mediante URIs, valores o nodos en blanco. Cada una de estas URIs denotan recursos, los valores son literales y los nodos en blanco referencian recursos anónimos en un grafo RDF. Están conectados por arcos dirigidos desde los nodos Sujeto hasta los nodos Objeto. Estos arcos representan predicados (Propiedades) y se identifican también mediante URIs: las propiedades también son recursos en la Web Semántica. Resumiendo, un grafo RDF es un conjunto de tripletas de la forma <s,p,o> donde,

s es un nodo Sujeto, que puede ser una URI o un nodo en blanco.
p es un arco Propiedad, un predicado binario identificado por una URI.
o es un nodo Objeto, que puede ser una URI, un nodo en blanco o un literal.

Existen varias formas de serializar un grafo RDF: mediante la sintaxis XML para representar grafos RDF, RDF/XML (sintaxis normativa^[29]), la sintaxis N-TRIPLES y la notación N3. También se puede representar un grafo RDF en una variante de la lógica de primer orden. Desde este punto de vista, un grafo RDF se corresponde con una conjunción de fórmulas atómicas binarias ^[30]: $\{ p(s,o) \ \wedge \ p'(s',o') \ \wedge \ ... \}$ ; No es posible, por ejemplo, expresar negaciones o disjunciones en las fórmulas y, tampoco, por extensión, implicaciones o expresiones del tipo de reglas. Las limitaciones de expresión del lenguaje RDF son evidentes y por eso se extendió en su momento mediante el RDF Vocabulary Description Language (RDF Schema o RDF(S))^[31]. Este lenguaje introduce un sistema de tipos muy básico para la Web Semántica y las nociones de clase definida extensionalmente como un conjunto de recursos (rdfs:Class) y propiedad (rdfs:Property). Además proporciona los mecanismos para especificar jerarquías de clases (rdfs:subClassOf), jerarquías de propiedades (rdfs:subPropertyOf)y la posibilidad de definir los dominios y rangos de las propiedades (rdfs:Domain y rdfs:Range). RDFS está pensado como una extensión de RDF que permita construir vocabularios y terminologías en la Web Semántica.

La decisión de adoptar RDF como modelo de datos para la descripción de recursos se basa en dos propiedades características de este lenguaje.

Es un lenguaje web, utiliza uso de URIs para denotar entidades.
La capacidad ilimitada de combinar grafos RDF. Semánticamente, si un grafo RDF es una conjunción de fórmulas atómicas binarias, la unión de varios grafos RDF es la conjunción de las fórmulas de cada grafo RDF. En términos de aplicación al proyecto, podemos combinar y mezclar diferentes vocabularios y modelos RDF, ya que sintácticamente son grafos RDF.

Estas propiedades son importantes para el proyecto EzWeb, ya que es una plataforma web y de ahí la importancia de utilizar un lenguaje que 1) esté basado en la Web y 2) nos permita desacoplar el modelo de datos que puede manejar con los propios datos. De esta forma, el modelo semántico puede ser extendido o modificado para incluir nuevos tipos de recursos, como nuevos gadgets, nuevos conceptos para la definición de los perfiles, etc.

[editar]

Ontologías y Lógica Descriptiva

Una ontología es una herramienta formal para describir la estructura y la conceptualización de un dominio, por lo general, mediante una jerarquía de clases de objetos del dominio y relaciones binarias, llamadas propiedades, que relacionan unas entidades con otras. Una ontología permite el razonamiento automático sobre un dominio, como inferir por ejemplo la pertenencia de las entidades del dominio a los conceptos que lo estructuran o el conjunto de entidades a las que se puede aplicar una propiedad. Sin embargo, el lenguaje RDFS es un lenguaje de definición de ontologías muy sencillo, con poco poder expresivo: no permite definir nuevas clases desde las que ya están declaradas, no permite operaciones como la disjunción, intersección o la negación, etc. Además presenta otros problemas como los descritos en ^[32]

El formalismo usual para la construcción de ontologías es la lógica de primer orden, especialmente una familia de lenguajes, las lógicas descriptivas (DL), que son un subconjunto decidible de la lógica de primer orden. La sintaxis de una lógica descriptiva se construye sobre tres alfabetos de símbolos:

Símbolos de clases: C, también conocidos habitualmente como conceptos.
Símbolos de propiedades: R, también conocidos como roles.
Símbolos de individuos o instancias: a, b.

Dependiendo del tipo de lógica descriptiva, se pueden utilizar diferentes constructores para la construcción de expresiones de clases y expresiones de propiedades. Intuitivamente, las expresiones de clase se usan para representar conjuntos de individuos de dominio y las expresiones de propiedades se usan para representar relaciones binarias sobre los individuos del dominio. Los símbolos de individuos se utilizan para representar a los individuos del dominio y se interpretan como constantes lógicas.

Técnicamente, un conjunto finito de axiomas en una lógica descriptiva se puede considerar una ontología. Existen actualmente varios lenguajes web basados en lógica descriptiva para la representación de conocimiento: OWL, DAML, OIL, DAML+OIL y WSML-DL. El Web Ontology Language (OWL) es una Recomendación del W3C con tres variantes: Lite, DL, Full.

Básicamente, una ontología en una lógica descriptiva, incluso en su forma más simple, ALC (Attributive Language with Complement), permite expresar axiomas para la construcción de una jerarquía de clases del tipo $X \sqsubseteq Y$ , donde son clases o expresiones de clase (ejemplo, $X \sqcup Y$ y donde la extensión de X es un subconjunto de la extensión de Y. También podemos tener una expresión de la forma $X \equiv Y$ , que sería un axioma de equivalencia y que se puede sustituir por los axiomas $X \sqsubseteq Y$ y $Y \sqsubseteq X$ . Un conjunto de axiomas de este tipo para describir los conceptos del dominio se denomina TBox.

Por otro lado, expresiones de la forma a:C y <a,b>:R, donde C es una expresión de clase, R es una expresión de propiedad y a,b son símbolos de individuo se denominan DL-atoms, y permiten expresar la pertenencia a una clase o a una propiedad. Un conjunto de asertos de este estilo se denomina ABox.

La semántica de una lógica descriptiva es una semántica de primer orden. Una interpretación I es un un par I = (W,.^I), donde W es un conjunto de entidades no vacío, llamado dominio, y .^I es la función de interpretación. Esta función mapea:

cada concepto C a un subconjunto C^I de W.
cada rol R a un subconjunto R^I de W x W.
cada individuo a a un elemento a^I de W.

Esta función se puede extender inductivamente para cubrir la interpretación semántica de descripciones de conceptos como las siguientes:

$C \sqcap D = C^{I} \cap D^{I}$
$C \sqcup D = C^{I} \cup D^{I}$
$(\neg C)^{I} = W - C^{I}$
$(\exists R.C)^{I} = \{a \in W \mid \exists \ b \in W \ con \ (a,b) \in R^{I} \wedge b \in C^{I}\})$
$(\forall R.C)^{I} = \{a \in W \mid \forall \ b \in W \ si \ (a,b) \in R^{I},\ entonces \ b \in C^{I}\})$

Existen dos motivaciones claras para utilizar lógica descriptiva a la de hora de construir ontologías en la Web Semántica. La primera es que permiten detectar inconsistencias en las descripciones. La segunda es que se puede derivar información implícita a partir de los axiomas de la ontología. Ambas propiedades de una ontología o conjunto de axiomas en una lógica descriptiva pueden ser reducidos a las siguientes tareas de razonamiento.

Dados los conceptos X, Y y un conjunto de axiomas T:

Satisfacibilidad: un concepto C es satisfacible respecto de T si existe como mínimo un modelo formal de T donde la interpretación de C, C^I, no está vacía.

Subsunción: un concepto D subsume un concepto C respecto de T ssi $C^{I} \subseteq D^{I}$ para cada modelo de T. También se puede escribir $C^{I} \subseteq_{T} D^{I}$

El razonamiento en la mayor parte de las lógicas descriptivas, por lo menos en lo que respecta a OWL-DL, es decidible y existen técnicas optimizadas implementadas en varios razonadores disponibles en el mercado (véase el entregable D.2.1.3.).

[editar]

EzWeb y el Lenguaje OWL (Web Ontology Language): OWL-DL

En el contexto de la Web Semántica, se espera que las ontologías ^[33],^[34], como artefactos para la representación formal de recursos, jueguen un papel central ayudando a automatizar los procesos de acceso a la información. En particular, se espera que las ontologías proporcionen vocabularios estructurados que expliquen las relaciones entre los diferentes conceptos de un dominio. El caso de EzWeb es similar: la definición formal de los recursos del catálogo, del perfil del usuario y de otra información relevante del contexto se espera que facilite el descubrimiento de nuevos gadgets, la adaptación de contenidos de acuerdo al contexto del usuario y mejore o facilite la comunicación entre los distintos gadgets que un usuario tenga seleccionados en su configuración personal de EzWeb. Esto hace que las ontologías sea la técnica de representación de conocimiento a tener en cuenta en primer lugar a la hora de afrontar el recubrimiento semántico de la plataforma.

El lenguaje OWL (Web Ontology Language) es la Recomendación del W3C para la construcción de ontologías en la Web Semántica^[35]. OWL es en realidad una familia de tres lenguajes diferentes:

OWL-Lite permite a usuarios que sólo necesitan mecanismos para la construcción de jerarquías de conceptos y restricciones siemples. OWL-Lite proporciona la semántica necesaria para desarrollar sistemas de clasificación como vocabularios controlados y taxonomías.
OWL-DL es el estándar de facto para la creación y el intercambio de modelos basados en ontologías en la Web. OWL-DL recibe su nombre por su correspondencia con una lógica descriptiva determinada y que estudiaremos más adelante: SHOIN(D). OWL-DL incluye todos los constructores del lenguaje OWL, pero sólo pueden ser usados bajo determinadas condiciones que garanticen un nivel de expresividad dentro de la lógica de primer orden (por ejemplo, una clase puede ser subclase de diferentes clases, pero una clase no puede ser instancia de otra clase.
OWL-Full proporciona la máxima expresividad y la libertad sintáctica de RDF. OWL-Full extiende tanto RDF como RDFS, de forma que cualquier grafo RDF es una ontología OWL-Full válida.

Se ha escogido OWL-DL como lenguaje para la descripción de la ontología del contexto en EzWeb. Esta variante de OWL proporciona una expresividad rica a las que vez que ofrece garantías sobre sus propiedades computacionales, existiendo en el mercado varios razonadores. Respecto a la relación entre OWL-DL y OWL Lite, éste es un subconjunto del primero. El caso de OWL-Full es diferente. OWL-Full no tiene una semántica formal basada en interpretaciones de primer orden (no tiene correspondencia con ninguna lógica descriptiva concreta, como las otras dos variantes del lenguaje) y su libertad semántica en el modelado no tiene garantías computacionales.

Además, la variante OWL-DL es el lenguaje para la construcción de ontologías que más acogida ha tenido tanto en el entorno académico como industrial. Actualmente está siendo revisado y extendido por el Grupo de Trabajo de OWL del W3C con el objetivo de lograr un lenguaje de ontologías más rico, OWL 1.1. Esta evolución de OWL deberá ser tenida en cuenta en caso de que los constructores que se proponen tengan interés para la ontología del contexto en EzWeb.

A continuación se presentan las características principales de este lenguaje:

Las entidades, ontologías y los constructores del lenguaje OWL se denotan mediante los identificadores de recursos en la Web, URIs (al igual que en RDF). Actualmente, el significado de una URI en RDF, y por tanto en OWL, es relativo a un grafo RDF en particular. En otras palabras, no se considera el significado de la misma URI en distintos documentos RDF. En este sentido, las URIs no son identificadores globales en la Web Semántica.

OWL proporciona un constructor especial, owl:imports, que permite incluir explícitamente información en una ontología de otras ontologías. Sin embargo, la única forma de operar de este constructor es importando en la ontología original todos los axiomas de la ontología importada. Esto puede tener problemas de consistencia (puede haber axiomas en las dos ontologías que sean incompatibles), incompatibilidad de estructura y no facilita la reutilización de conceptos o descripciones de forma independiente de la ontología donde están definidos.

OWL no realiza la Asunción de Nombre Único (UNA), como ocurre en las lógicas descriptivas. Así, dados dos objetos a,b, en lógica descriptiva denotan dos entidades diferentes en su interpretación semántica. En OWL, dos objetos pueden ser el mismo si no se dice lo contrario. Para ello proporciona dos constructores: owl:sameAs y owl:differentFrom.

Desde el principio, el objetivo ha sido guardar la máxima compatibilidad con el modelo de datos RDF y lenguaje RDFS, proporcionando una sintaxis normativa RDF/XML para el lenguaje OWL. Cualquier ontología OWL-DL puede mapearse a un conjunto de tripletas RDF. Con el objetivo de poder ser procesado por aplicaciones, las tripletas RDF se pueden representar usando la sintaxis XML para RDF, RDF/XML, que es la sintaxis normativa también de RDF.

Asunción de Mundo Abierto (OWA). Si una proposición p no está dicha explícitamente en una ontología, entonces no se puede inferir si p es verdadero o falso. La posición opuesta es la asunción de mundo cerrado (CWA), si p no está definido en la base de conocimiento, entonces p es falso.

Propiedades de anotación. OWL permite añadir metadatos a las clases, propiedades e individuos, como puede ser el caso de las propiedades rdfs:seeAlso o rdfs:comment. En el caso de OWL-DL, estas propiedades no se pueden usar en axiomas dentro de la ontología. Son propiedades fuera del dominio y no forman parte del vocabulario de la lógica descriptiva que está detrás de OWL. Además, en OWL-DL los conjuntos de propiedades de objeto, de tipo dato y anotación son obligatoriamente mutuamente disjuntos.

[editar]

Reglas en EzWeb

Mientras que W3C define el lenguaje OWL como estándar para la construcción y desarrollo de ontologías web, no existe por ahora un estándar para la definición de sistemas de reglas en la web. En relación a esta cuestión, tampoco hay un consenso generalizado qué tipo de información conviene representar mediante sistemas de reglas y qué información es necesaria representar mediante ontologías, ya que además se plantean problemas de integración y combinación entre los dos tipos de sistemas de representación de conocimiento (véase^[36] para posibles usos de los sistemas de reglas en la Web).

En una primera aproximación a la implementación del contexto en EzWeb, las reglas son necesarias para la definición de las políticas de preferencias de los usuarios (véase la sección "Modelo Conceptual" de este mismo entregable). Debido a esto es necesario plantearse qué tipo de integración entre ontologías y reglas es deseable para la construcción de este componente semántico en EzWeb. A continuación planteamos tres posibilidades:

La combinación directa entre sistemas de reglas y RDF. En este caso, se podrían utilizar reglas de producción basadas en RDF, como es el caso de Jena Semantic Framework, o utilizar el operador CONSTRUCT del lenguaje de consultas para RDF, SPARQL. Esta solución es la que ha utilizado para ejemplificar el ejemplo de preferencia de usuario descrito en la sección "Modelo Conceptual" de este mismo entregable.
La combinación entre ontologías y sistemas de reglas. Técnicamente la combinación de estos dos sistemas de representación de conocimiento se limita a la posibilidad de combinar lógicas descriptivas y lógicas Horn. El resultado de la unión de estos dos sistemas lógicos es un lenguaje no decidible y no completo. Existen actualmente varias aproximaciones para la combinación del lenguaje OWL-DL (o subconjuntos del mismo) con reglas.
1. Extensión directa de OWL-DL para la expresión de reglas: SWRL y su subconjunto DL-Safe Rules^[37].
2. Combinación híbrida de bases de conocimiento en OWL-DL y en un lenguaje de reglas^[38]. Mientras que las ontologías proporcionan la conceptualización del contexto y definen las entidades que participan en él, las reglas se definen independientemente pero utilizando los conceptos y propiedades que ya se han definido en la ontología. En este caso, no se construye un nuevo lenguaje, como en SWRL, sino que las reglas se colocan de forma independiente encima de la ontología. Esto hace posible la integración de razonadores existentes para sistemas de reglas junto con razonadores para ontologías, sin tener que desarrollar uno nuevo desde el principio. Esta aproximación es parecida a la combinación de reglas y RDF, con la salvedad que la integración no es directa como en el primer caso y habrá que decidir qué nivel de expresividad de ontología es compatible con la integración con un sistema de reglas. En este sentido habrá que tener en cuenta, la intersección entre la lógica descriptiva y la lógica Horn: Description Logic Programming (DLP), ya que puede ser un nivel de expresividad suficiente para la construcción de la ontología del contexto y nos permitiría una integración directa con sistemas de reglas conocidos.
Utilizar un único lenguaje para la expresión de las ontologías y reglas basado en F-Logic^[39]. Este lenguaje extiende el cálculo de predicados clásico con los conceptos de objetos, clases y tipos, que se han adaptado de la programación orientada a objetos. F-Logic se ha sugerido en varios sitios como posible lenguaje para la construcción integrada de ontologías y reglas ya que el estilo de modelado es en muchos casos (por ejemplo, relación de subclase o instancia)es similar a OWL. TRIPLE^[40] es un lenguaje de reglas basado en F-Logic especialmente diseñado para el tratamiento de tripletas RDF.

Actualmente, el W3C está trabajando en el desarrollo de una lenguaje web para el intercambio de reglas, de forma que diferentes sistemas de reglas puedan intercambiar información utilizando este nuevo lenguaje, denominado RIF (Rule Interchange Format^[41] ^[42]). El uso de este lenguaje para la definición de la políticas de preferencias de los usuarios puede ser relevante en el caso de que no se pretenda dentro del proyecto decantarse por un razonador y lenguaje determinado, dejando abierta esta elección a cada implementación particular de EzWeb. De esta forma, las reglas serían multiplataforma y podrían ser ejecutadas en diferentes motores de reglas.

[editar]

Formalización del Contexto

Hasta ahora, se ha hecho un breve repaso sobre el estado del arte en técnicas de representación de conocimiento en la Web Semántica, desde el modelo de datos básico que se corresponde con las tripletas RDF, hasta el uso de lógicas específicas para ontologías o sistemas de reglas. La definición del contexto en EzWeb utilizará, como resto el de la plataforma, el modelo de datos RDF.

La formalización del contexto consistirá en los siguientes elementos:

Modelo conceptual del contexto: se formalizará la noción de contexto aplicada al usuario (UserContext) y a la propia plataforma (EzContext). El modelo recogerá los conceptos genéricos necesarios para la definición del contexto en EzWeb como el perfil del usuario, el usuario, los gadgets de la plataforma, etc. Además recogerá una serie de propiedades que permita relacionar las distintas entidades que configuran el contexto: refines, plays, etc.
Este modelo se implementará utilizando una ontología, probablemente utilizando el lenguaje OWL-DL, el lenguaje estándar para la construcción de ontologías web. En cualquier caso, este modelo no debería en un principio recoger axiomas específicos para la definición de los diferentes conceptos. Las propias implementaciones de la plataforma deberían ser las que decidan el nivel de expresividad y qué definición es conveniente para sus usos. De esta forma, en caso de que alguien no quisiese utilizar los constructores OWL-DL para la formalización del contexto, no estaría obligado a ello y podría mantenerse en un nivel de expresividad que garantizase una integración directa con otros sistemas de conocimiento, probablemente basados en reglas.
Preferencias de los usuarios: las preferencias constituyen las políticas de configuración de la plataforma EzWeb. El formalismo más adecuado para la expresión de estas políticas posiblemente sean expresiones en forma de reglas. Estas preferencias no deberían añadir nuevos conceptos al modelo, sino definir nuevas relaciones que no pueden ser definidas a priori en una ontología expresada en lógica descriptiva. En cualquier caso, son los usuarios los que deben definir su propia política de preferencias: EzWeb sólo debe proporcionar su definición formal, cómo se integran con el modelo del contexto y las herramientas necesarias para su edición, pero no formarán parte del propio modelo.

[editar]

D 2.1.3 Mecanismos de transmisión del contexto a los servicios de back-end

[editar]

Introducción

Si se pretende enriquecer el funcionamiento global de la plataforma EzWeb con el conocimiento que albergará la descripción semántica del contexto (descrita en el entregable D.2.1). Por tanto se debe proveer de mecanismos eficientes para que ese conocimiento sea transmitido entre los diferentes componentes que interaccionan.

En el entregable D.3.1.1 se sientan las bases para la construcción de una plataforma de mashup sensible al contexto, por lo que ese documento será tomado como base para estudiar con detalle los distintos componentes de la futura plataforma que necesitarán acceso al contexto.

El contexto en EzWeb

Hay tres cuestiones muy claras a diferenciar:

Cómo se construye el contexto, y se actualiza a partir de fuentes externas
Cómo se accede al contexto por parte de los componentes de la plataforma
Cómo se transmite el contexto a servicio de back-end

Estudiando la arquitectura de alto nivel propuesta, se han analizado diferentes flujos de información para el contexto entre los distintos componentes.

Acceso al contexto (casos de uso)

Estos flujos se materializan en varios casos de uso, tanto para el acceso como para la transmisión del contexto.

[editar]

Casos de uso de acceso al contexto

[editar]

Caso 1: consultas de la plataforma al contexto

Véase el caso de uso 1 del entregable D.2.1.1.

[editar]

Caso 2: consultas de los gadgets (activos) al contexto

Véase el caso de uso 2 del entregable D.2.1.1.

[editar]

Caso 3: consultas al contexto como ayuda al sistema de matchmaking

Véase el caso de uso 3 del entregable D.2.1.1.

[

Vistas

Navegación

Buscar

Herramientas

D 2.1 Descripción semántica del contexto

De MorfeoWiki

Tabla de contenidos

D 2.1.1 Estado de la ciencia y análisis de requerimientos de las técnicas semánticas de modelado de contexto

Introducción

Aplicación del contexto al proyecto EzWeb

Caso de uso 1 (Uso de información contextual por la plataforma EzWeb)

Caso de uso 2 (Uso de información contextual por las aplicaciones mashup)

Caso de uso 3 (Uso de información contextual para recuperar recursos del Catálogo de EzWeb)

Contexto y perfil de usuario

Vocabulario FOAF

Vocabulario SIOC

Extensiones e integración con otros vocabularios

Contexto y situación

Teorías formales del contexto

Ontología de las Situations&Descriptions

Contexto y aplicaciones sensibles al contexto

Context Toolkit

AmbieSense

Evaluación

D 2.1.2 Conceptualización e implementación de la ontología de modelado del contexto

Introducción

Modelo conceptual del Contexto en EzWeb

UserContext

EzContext

Políticas de preferencias e intereses de usuario

Representación de conocimiento en la Web Semántica

Lógica en la Web Semántica

EzWeb y Resource Description Framework (RDF)

Ontologías y Lógica Descriptiva

EzWeb y el Lenguaje OWL (Web Ontology Language): OWL-DL

Reglas en EzWeb

Formalización del Contexto

D 2.1.3 Mecanismos de transmisión del contexto a los servicios de back-end

Introducción

Casos de uso de acceso al contexto

Caso 1: consultas de la plataforma al contexto

Caso 2: consultas de los gadgets (activos) al contexto

Caso 3: consultas al contexto como ayuda al sistema de matchmaking