D 4.1 Técnicas de descubrimiento de recursos en función del contexto

De MorfeoWiki

Tabla de contenidos 1 Introducción 2 D 4.1.1 Métodos y técnicas para la extracción de información sobre el comportamiento del usuario en distintos entornos 2.1 Creación del contexto de usuario 2.1.1 Técnicas de creación del contexto de usuario 2.2 Características del contexto relevantes en el descubrimiento de recursos 3 D 4.1.2 Maquinarias de reglas para aplicar el contexto al proceso de descubrimiento de recursos 3.1 Análisis de motores de reglas de inferencia 3.2 Diseño de la arquitectura del motor de reglas para aplicar el contexto en el descubrimiento de recursos y en la búsqueda personalizada 4 D 4.1.3 Marco de arquitectura flexible y distribuida para la aplicación del contexto al proceso de descubrimiento de recursos 4.1 Creación del contexto de usuario 4.1.1 Feedback de la plataforma de ejecución 4.1.2 Adquisición de datos de otros sitios 4.2 Proceso de inferencia de resultados mediante el contexto de usuario 4.3 Devolución de resultados al usuario 4.3.1 Búsqueda inteligente de recursos 4.3.2 Descubrimiento de recursos basado en el contexto 5 D 4.1.4 Protocolos de comunicación para transmitir el contexto 5.1 Análisis de arquitecturas y protocolos de comunicación/sindicación de contenidos 5.1.1 Análisis de arquitecturas cliente/servidor Web basadas en el protocolo HTTP) 5.1.1.1 Servicios Web 5.1.1.2 REST 5.1.1.3 RSS 5.1.1.4 XML-RPC 5.1.2 Análisis de otras arquitecturas distribuidas 5.1.2.1 P2P 5.2 Diseño del protocolo de transmisión del contexto de usuario 6 Conclusiones y Futuras Mejoras 6.1 Conclusiones 6.2 Futuras Mejoras 7 Referencias

Introducción

En el ámbito del proyecto EzWeb, es fundamental considerar la noción de una plataforma marketplace de recursos. También llamado catálogo aglutina un conjunto heterogéneo de gadgets, servicios y contenidos, entendidos como recursos accesibles y susceptibles de ser explotados en el entorno operacional de la plataforma EzWeb. El catálogo ha de ser capaz de devolver un conjunto de resultados a partir de una búsqueda realizada por el usuario. Pero para poder aprovechar totalmente la funcionalidad de EzWeb es necesario tener en cuenta, por ejemplo, qué recursos pueden componerse con otros para ofrecer una información más precisa o adecuada para el usuario, o que gadgets pueden conectarse con otros para ofrecer una funcionalidad completa. Por ello, la búsqueda tradicional entre un conjunto disconexo de recursos no es suficiente, ya que no se contemplan mecanismos para relacionar unos resultados con otros, para priorizar ciertos resultados, o incluso para devolver aquellos recursos más interesantes o útiles para el usuario.

El presente documento muestra una posible solución para los problemas planteados. En él se describe cómo el proceso de búsqueda y descubrimiento de recursos puede optimizarse aplicando conocimiento contextual. Para ello, se analizan los distintos aspectos relativos a la personalización de resultados: cómo se le presentan al usuario los recursos disponibles, cuáles son los resultados de una búsqueda concreta y qué recursos se recomiendan como más útiles para un usuario concreto. Todos estos resultados están sujetos a criterios de ordenación o ponderación en base a distintos baremos, incluyendo las necesidades del usuario. La información necesaria para realizar esta tarea se obtiene de datos explícitos que haya aportado el usuario, y de otros extraídos del entorno de ejecución del usuario y del uso previo de la plataforma, conformando todo ello el contexto de usuario. Además, esta información se complementa con el conocimiento extraído de la forma en la que los usuarios se relacionan dentro de la red social que rodea a la plataforma.

Para realizar esta tarea se describen las técnicas de extracción de conocimiento relativo al contexto, basándose en el uso de la plataforma y el comportamiento del usuario en distintos entornos. Posteriormente, se estudian qué aspectos del contexto son relevantes para el descubrimiento de recursos. Este estudio desemboca en una arquitectura de referencia de los mecanismos necesarios para aplicar el contexto en el descubrimiento, incluyendo protocolos de comunicación para transmitir el contexto, puesto que éste puede ser distribuido. También se incluye un estudio acerca de los diferentes métodos de aplicación del contexto en la plataforma. Por último, se desarrollan los motores de inferencia que permiten que el conocimiento de contexto ya extraído se pueda aplicar al descubrimiento y presentación de recursos.

El objetivo final de este entregable, es presentar la arquitectura final de la plataforma marketplace, con respecto a la búsqueda y descubrimiento de los recursos referenciados e indexados en ella.

D 4.1.1 Métodos y técnicas para la extracción de información sobre el comportamiento del usuario en distintos entornos

El contexto de usuario está compuesto de dos tipos de características^[1]: perfil de usuario y entorno de ejecución.

El perfil de usuario se refiere a factores humanos pueden dividirse en tres categorias:

• Información acerca del usuario, por ejemplo conocimiento sobre sus hábitos, estado emocional o condiciones biofisiológicas.
• El entorno social del usuario, como co-localización sobre los demás, interacciones sociales o dinámicas de grupo.
• Las tareas del usuario, como tareas programadas o asignadas, actividades espontáneas u objetivos generales.

Por otro lado el entorno de ejecución se refiere a los factores del entorno físico que pueden a su vez subdividirse en tres categorías:

• Localización, como posición absoluta, posición relativa o co-localización.
• Infraestructura, como recursos computacionales, de comunicación o rendimiento.
• Condiciones físicas, como ruido o luz.

El objetivo fundamental de una aplicación que pretenda ser sensible al contexto es adquirir toda la información de este tipo como sea posible, para poder ofrecer al usuario una interfaz e información personalizada. En el caso concreto del proyecto EzWeb, el objetivo final es ofrecer al usuario los recursos más útiles y más adaptados a su contexto. Para ello es necesario estudiar las técnicas de extracción de conocimiento, y así poder construir un contexto lo más extenso y preciso posible.

El presente capítulo analiza el proceso de creación del contexto de usuario, estudiando las diferentes técnicas para ello. Se analiza el estado del arte en técnicas de extracción de conocimiento, así como métodos automáticos o semiautomáticos de extracción del comportamiento del usuario. Fundamentalmente se concluyen qué características son necesarias para el descubrimiento y búsqueda de recursos sensible al contexto.

Creación del contexto de usuario

El contexto de usuario es un conjunto de datos heterogéneo, los cuales han de obtenerse de fuentes diversas. Por ello, no es posible abordar la adquisición de datos para construirlo de una manera uniforme. Cada conjunto de datos requiere de una técnica diferente, que se determina en este capítulo.

Sin embargo, gran parte del contexto de ejecución se obtiene automáticamente de la solicitud del navegador, mediante las cabeceras HTTP^[2] que contienen entre otros datos la dirección IP, el sistema operativo del cliente o el navegador utilizado. Esta información se analiza directamente extrayendo los campos de la cabecera HTTP cuando se reciba la petición en el servidor.

Existen algunas características del contexto de ejecución, como pueden ser el conjunto de aplicaciones instaladas en el cliente, la localización exacta de la solicitud o nivel de batería en un terminal móvil, que se envían junto con cada petición, pero que se pueden extraer del cliente y ser enviadas al servidor de manera automática junto con las peticiones que se realicen. Es decir, son datos objetivos y fácilmente medibles, por lo que no se requiere ningún proceso de inferencia para obtenerlos. Las condiciones físicas como el ruido o la luz no se consideran en el ámbito de EzWeb, pero en cualquier caso sólo serían necesarios los sensores adecuados para obtener los valores deseados.

Algunas características del perfil de usuario, como nombre, edad u ocupación, ha de indicarlas a la plataforma el propio usuario de manera explícita mediante una herramienta proporcionada por la plataforma. Estas características también son datos objetivos que no necesitan un proceso de inferencia posterior.

Las características más útiles del perfil de usuario, como intereses, aficiones, hábitos, estado emocional o entorno social, son las más complejas de obtener, y no son valores objetivos. Es necesario determinar de que valores objetivos se pueden inferir, así como qué proceso ha de seguirse para obtenerlas. Para realizar esta tarea se analiza qué técnicas de extracción de conocimiento se han aplicado tradicionalmente en la Ingeniería del Conocimiento y el Data Mining (KDD), estudiando además la aproximación social a la extracción de conocimiento obtenido a través de redes sociales y en general las ideas propuestas por la Web 2.0.

Técnicas de creación del contexto de usuario

En MyMobileWeb: D3.2.2 Especificación de ontologías avanzadas para la descripción del perfil de usuario]] se definen una serie de ontologías existentes para modelar el contexto de usuario. Dicho documento trata únicamente el perfil de usuario separándolo del contexto de ejecución y dejando la tarea de modelado de ontologías que lo representen para otro entregable del mismo proyecto (MyMobileWeb: D3.1.2). Dentro del proyecto EzWeb, hay que entender el contexto de usuario como una unión de las anteriores facetas, el perfil de usuario y del contexto de ejecución actual.

En cualquier caso, las ontologías descritas en ambos documentos son insuficientes para representar la información necesaria para presentar al usuario los recursos que más se adapten a su perfil. Además, no se describe en estos documentos el proceso a seguir para generar estas ontologías.

En el entregable del proyecto EzWeb D.2.1 Descripición Semántica del Contexto, se cubre la creación del contexto de usuario, por lo que el análisis de las técnicas de creación del contexto, la descripción del proceso de creación y los resultados obtenidos, forman parte de dicho entregable y no se desarrollan en el presente documento, que sin embargo utiliza sus conclusiones.

Características del contexto relevantes en el descubrimiento de recursos

A continuación se describen las características del contexto de usuario, que puede aprovecharse para mostrar al usuario resultados adecuados a sus necesidades.

• Contexto de ejecución:
  • Terminal desde el que se accede a la plataforma: Es la característica principal del contexto de ejecución, y un aspecto fundamental a la hora de devolver recursos. Por ejemplo, si un usuario esta accediendo desde un dispositivo móvil se devuelven sólo aquellos recursos visuales que puedan mostrarse en un tamaño reducido, y sin efectos gráficos complejos, ya que la pantalla de un móvil puede no permitir mostrar imágenes o controles avanzados. Además también hay que considerar la plataforma software desde la que se pretenden descubrir recursos. Por ejemplo si un usuario no ha instalado el plugin para flash, los recursos que hagan uso de esa tecnología se eliminan del conjunto de resultados.
  • Localización física y temporal: La plataforma ha de ser consciente de la localización física del dispositivo que realice la petición para ofrecerle los resultados más adecuados. Por ejemplo, si el usuario desea acceder a un servicio de reserva de restaurante, los resultados se ponderan, ofreciendo primero los restaurantes más cercanos a localización actual del dispositivo.
  • Como una especialización de lo anterior, la plataforma es consciente de la localización "lógica" del usuario. Posibles estados serían encontrarse en el trabajo, en casa o en una reunión. Hay que hacer notar que esta característica es una mezcla entre contexto de navegación y perfil de usuario. De hecho, cabe la posibilidad de que sea el usuario el que explícitamente indique si se encuentra trabajando o en casa. Es fundamental tener esta característica en cuenta, dado que el usuario está interesado en recursos distintos según su actividad actual. Por ejemplo, si está trabajando se le ofrecen recursos para manejar los sistemas de información de la empresa, o si se encuentra en su casa se le ofrecen recursos para gestionar sus contactos, el correo electrónico personal, o incluso para manejar la calefacción u otros dispositivos domésticos.

• Perfil de usuario: En el caso del perfil de usuario las características principales a considerar son aquellas relativas a los intereses del usuario: se devuelven recursos compatibles o que pueden interaccionar con otros recursos que ya esté usando el usuario y se recomiendan recursos similares o mejores a otros que ya haya usado. Además, cobra muchísima importancia la comunidad de usuarios: se recomiendan o descubren recursos usados por usuarios con intereses similares

D 4.1.2 Maquinarias de reglas para aplicar el contexto al proceso de descubrimiento de recursos

Una vez modelado el contexto de usuario, e identificados los procesos y mecanismos necesarios para extraerlo y almacenarlo, es importante determinar el modelo de datos que almacena este conocimiento. Obviamente, una ontología^[3] es una opción muy adecuada, ya que es un formalismo muy extendido para modelar y almacenar conocimiento. Una ontología es un modelo de datos que representa un conjunto de conceptos en un dominio y las relaciones entre esos conceptos.

De una ontología y sin otras herramientas no es posible extraer más conocimiento que los conceptos almacenados en ella. Sin embargo, dada su organización, es sencillo razonar sobre ella, utilizando un razonador o motor de reglas de inferencia. Estas herramientas permiten razonar nuevas relaciones o conceptos no explícitos en una ontología, permitiendo además realizar consultas sobre ella.

Como ya se ha mencionado anteriormente, hay otras posibilidades para almacenar el contexto de usuario, como puede ser un conjunto de etiquetas o folksonomía. En cualquier caso, cualquier modelo que se elija almacena la información de contexto de una manera estática. Dados los requisitos del proyecto EzWeb, es necesario extraer dicha información y razonar sobre ella para generar conocimiento que sea utilizado en el descubrimiento y búsqueda inteligente de recursos.

En el presente documento se estudian los distintos motores de reglas que permitan razonar a partir del contexto un proceso de búsqueda de recursos en el catálogo. Una vez elegido el motor más adecuado se diseña la arquitectura que permita usar el motor de reglas que aprovecha el contexto para descubrir los recursos más interesantes para el usuario. Para ello, se definen las consultas que han de realizarse al motor de reglas y se determina cómo tratar los resultados proporcionados.

Análisis de motores de reglas de inferencia

Los principales razonadores semánticos toman como entrada una ontología y realizan un proceso de inferencia sobre ella. A continuación se resumen algunos de ellos [1]:

• Bossam: Motor de reglas basado en el algoritmo RETE^[4]. Soporta razonamiento sobre ontologías en OWL, en SWRL y reglas RuleML.
• Hoolet: Razonador para ontologías en OWL-DL.
• Pellet: Razonador Java de código abierto para OWL-DL.
• KAON2: Infraestructura de de razonamiento para ontologías OWL-DL, SWRL y F-Logic, bastante veloz y comparable a razonadores como Fact y Racer, también implementa la interfaz DIG.
• RACER: Sistema Razonador de Web Semántica que ofrece una interfaz HTTP.
• Jena: Framework en Java para desarrollar ontologías. Suele utilizarse en combinación con un razonador como RACER o Pellet.
• FaCT: Clasificador de Lógica Descriptiva (DL).
• FaCT++: Versión avanzada del razonador anterior.
• SweetRules: Conjunto integrado de herramientas para gestionar reglas de Web Semántica y ontologías.
• Protégé: Entorno Java para OWL y OKBC, permite exportar a otros formatos y puede extenderse mediante una API. Esta concebido como una plataforma básica a la que se le pueden añadir múltiples funcionalidades en forma de plugins.

NOTA - ¿No se realiza esta implementación en 2.2?, en tal caso eliminar la duda y decir que estamos haciendo.

Como se puede ver, no existen razonadores para inferir conocimiento a partir de una folksonomía o un conjunto de datos no organizado. Si se modelara el contexto de usuario con alguno de estos formalismos, habría que implementar el razonador ad-hoc al modelo de datos elegido.

En cualquiera de los casos, tanto si se elige un razonador o se implementa uno, los requisitos fundamentales del razonador para ofrecer descubrimiento y búsqueda inteligente son los siguientes:

• Licenciamiento abierto. Dado el carácter global del proyecto EzWeb, el razonador elegido debería distribuirse en código abierto. Así si la funcionalidad ofrecida no satisface plenamente los requisitos se puede modificar/añadir funcionalidad de manera sencilla.
• Ofrecer una API adecuada. Dado que el razonador no va a ser una herramienta de uso final, sino que es utilizada por la plataforma, se necesita una API de acceso a la funcionalidad del razonador, para poder integrar éste en la arquitectura global del catálogo. Sería deseable que ofreciese una interfaz uniforme tipo REST, para que su acceso sea homogéneo con respecto al resto del proyecto EzWeb.

NOTA - ¿hay más requisitos?

Este es un estudio centrado en el desarrollo del catálogo. En D.2.1.3 Razonador para la ontología de modelado del contexto, se analizan más en detalle éstos y otros razonadores disponibles para extraer conocimiento del contexto de usuario, eligiendo el más adecuado para los datos de contexto modelados dentro del proyecto EzWeb. En el diseño de la arquitectura que permita la recomendación y el descubrimiento inteligente de recursos se utiliza el razonador elegido en el entregable D.2.1.3.

Diseño de la arquitectura del motor de reglas para aplicar el contexto en el descubrimiento de recursos y en la búsqueda personalizada

Como ya se ha mencionado anteriormente, el diseño de la arquitectura necesaria para aplicar el contexto en el descubrimiento de recursos, depende en gran medida del motor de reglas elegido (tarea que ha de realizarse en el entregable D.2.1.3). Dado que en dicho entregable no se ha elegido aún un motor de reglas adecuado (debido principalmente a la temprana fase del proyecto, y a que aún quedan diversos aspectos que concretar), el diseño correspondiente a esta sección se pospone para una siguiente fase del proyecto.

D 4.1.3 Marco de arquitectura flexible y distribuida para la aplicación del contexto al proceso de descubrimiento de recursos

En los capítulos anteriores del presente entregable se han analizado las distintas características del descubrimiento y búsqueda de recursos sensible al contexto analizando características del contexto relevantes a la búsqueda de recurso, estudiando los distintos razonadores y eligiendo el más adecuado. El presente capítulo aplica los puntos anteriores al diseño del catálogo, en concreto en el descubrimiento inteligente y recomendación de recursos. La arquitectura global del catálogo EzWeb puede encontrarse en la wiki de desarrollo [2] Este capítulo, por lo tanto, analiza los distintos aspectos que ha de considerar la arquitectura de la plataforma para que esta sea context-awareness respecto de la búsqueda y descubrimiento de recursos. La arquitectura ha de contemplar cómo adquirir los datos necesarios para construir el contexto de usuario, incluyendo el proceso de evolución del perfil del usuario en base al uso de la plataforma. Posteriormente se define el proceso de búsqueda y descubrimiento de recursos, enriquecido por inferencias realizadas sobre el contexto de usuario.

Creación del contexto de usuario

Este apartado describe la arquitectura necesaria de la plataforma para construir el contexto de usuario, relativo al descubrimiento inteligente de recursos. La construcción del contexto de usuario se trata en el entregable D.2.1.2, por lo que en este apartado sólo se incluyen aquellos aspectos más relevantes para la recomendación y descubrimiento inteligente de recursos.

Feedback de la plataforma de ejecución

Relativo al descubrimiento y la búsqueda de recursos, es importante añadir a lo mencionado en otros entregables estos aspectos a considerar:

• Conexión de recursos: Si muchos usuarios conectan un recurso con otro, la plataforma debería recomendar uno como complementario al otro, por lo que esta inoformación deberá ser almacenada.
• Conjunto de recursos añadidos: los recursos que un usuario tiene añadidos en su entorno tienen una semántica asociada (por medio de ontologías o tags, o cualquier otro mecanismo). Por tanto, el conjunto de recursos de un usuario está definiendo en parte al usuario para futuras recomendaciones.
• Uso de los recursos: El catálogo tiene información sobre el uso de los recursos que puede almacenar la plataforma, como número de usuarios con un recurso añadido a su paleta o número de instancias que se están usando. Esta información ha de aprovecharse para recomendar a los usuarios los recursos más adecuados a su perfil.

Adquisición de datos de otros sitios

Además de observar el comportamiento del usuario dentro de la plataforma es posible aprovechar las ventajas de la Web 2.0 y las redes sociales. Existen numerosos sitios que almacenan un perfil de usuario, como por ejemplo flickr, last.fm, del.icio.us o facebook. Casi todos ellos ofrecen una API de acceso a estos datos y en la mayor parte de los casos ese perfil es público. Por ejemplo en last.fm se muestran los gustos musicales de todos los usuarios, en flickr las fotos, y en del.icio.us los bookmarks. Por tanto, si se establece un sistema de federación de identidad como OpenID es posible construir parte del contexto de usuario de manera directa. En tal caso será necesario algún mecanismo de confianza o trust que permita al usuario indicar cual es su cuenta en estos sistemas y permita además acceder a los datos de su perfil. Es posible incluso acceder al mismo sin duplicar la información, generando un contexto distribuido como se detalla en el siguiente capítulo de este entregable. Es deseable también investigar algún mecanismo de descubrimiento semi-automático de las cuentas de usuario en otras plataformas.

A continuación se resumen los principales sitios que almacenan información del usuario susceptible de ser utilizada por la plataforma marketplace:

• del.icio.us [3] es un sitio de bookmarking colaborativo, existen otros muchos como simpy, furl o spurl, pero no han alcanzado la popularidad de del.icio.us. Esta herramienta permite etiquetar sitios Web y almacenarlos como favoritos, utilizando etiquetas o tags libres para categorizarlos. Los bookmarks de un usuario son accesibles para toda la comunidad. Además, ofrece una API que sigue la filosofía REST para acceder a los bookmarks y tags de un usuario. El conjunto de tags que un usuario ha utilizado en sus bookmarks, así como los propios bookmarks que almacena, definen en parte al usuario. El catálogo almacena o accede a esta información para aprovecharla posteriormente. Se plantean varios escenarios de uso aprovechando los datos de del.icio.us o de otros sistemas de bookmarking social:
  • Se le pueden recomendar al usuario aquellos recursos que estén etiquetados con las mismas o similares etiquetas a las que almacena en su perfil de otra plataforma. De este modo se devuelven recursos "similares" al usuario.
  • Dos usuarios son similares si tienen perfiles en otras plataformas similares, sean conjuntos de tags y/o conjuntos de bookmarks. Por tanto, si se encuentran similitudes entre dos usuarios se les ofrecerán los recursos que está usando el otro.
  • Dada una búsqueda concreta que haga un usuario, se ponderan los resultados con respecto a los tags usados en otras plataformas o en función de las URLs. Por ejemplo, si un usuario tiene un bookmark de un dominio, www.w3.org, y existe un recurso con raíz en el mismo dominio o referenciando a un autor en ese dominio se devuelve primero ese recurso.

• last.fm [4] es una comunidad en la que los usuarios manifiestan sus gustos musicales. Desde casi cualquier reproductor de música es posible enviar información a la aplicación de las canciones que se están escuchando en cada momento. De esta forma, la aplicación recopila los gustos musicales de cada usuario, permitiendo encontrar otros usuarios con intereses similares. Este perfil de usuario generado es de acceso público y se pueden ver los gustos de cualquier usuario. Además, establece qué grupos son de estilos similares, recomendando al usuario grupos que nunca ha escuchado, pero que se parecen a los que le gustan. La página last.fm ofrece una API basada en Servicios Web que permite acceder a su información. Un escenario de uso probable si se consultan los gustos musicales del usuario en last.fm sería:
  • Mostrar a un usuario gadgets relacionados con la música si este tiene un perfil activo en last.fm, o incluso personalizar un gadget de información de conciertos a aquellos de sus grupos preferidos.

Estos son dos ejemplos de los múltiples existentes. El perfil de usuario es algo muy complejo y muy variado que abarca múltiples áreas. Siguiendo la filosofía de la Web 2.0, es muy interesante aprovechar el trabajo de recopilar y construir parte de ese perfil, realizado por otras aplicaciones Web. De otra forma, existirá parte del perfil de usuario que jamás será capaz de conocer la plataforma.

Proceso de inferencia de resultados mediante el contexto de usuario

Devolución de resultados al usuario

El objetivo final de almacenar el contexto de usuario para el catálogo es devolver al usuario los recursos más útiles para él. En la siguiente sección se muestra cómo mejorar los resultados en las búsquedas y como ofrecerle automáticamente al usuario los recursos que se adapten mejor a su perfil.

Búsqueda inteligente de recursos

El escenario planteado para la búsqueda de recursos es el siguiente: Un usuario, con un perfil conocido por la plataforma, desea buscar un recurso que satisfaga una necesidad que ha detectado. Por ejemplo, un gadget que monitorice una red dada y muestre el tráfico. Para ello, realiza una búsqueda en el catálogo introduciendo las etiquetas que definen el gadget buscado: en el ejemplo anterior "lan" y "analyzer". El funcionamiento de la plataforma para este caso es el siguiente:

La plataforma busca en la colección de de recursos y devuelve todos los que estén etiquetados con las etiquetas indicadas, y en caso de un sistema de búsqueda complejo con lógica borrosa o similar, con etiquetas parecidas o aproximadas.

Como se puede observar, el contexto todavía no ha entrado en juego. Sin embargo, la clave de este proceso está en la ordenación de resultados. Está demostrado^[5] que usando un sistema de búsqueda, la mayoría de los usuarios no acceden más allá de la primera página de resultados o incluso de los cinco o diez primeros. Por tanto, es fundamental devolver el recurso más adaptado al usuario el primero o de los primeros, independientemente del resto de recursos existentes.

Por ello, la plataforma ha de tomar el conjunto total de resultados y ordenarlos de acuerdo con los siguientes criterios, ponderados adecuadamente. Esta ponderación es un aspecto a considerar más adelante y habría que determinar qué es más importante, incluyendo la opción de dejar esa elección al usuario:

• Criterios no relativos al contexto:
  • Número total de usuarios que están utilizando ese recurso, ya que un recurso poco utilizado probablemente no sea bueno.
  • Valoración de los usuarios del recurso.
• Criterios asociados al contexto:
  • Conjunto de tags del recurso. Si dicho conjunto de tags es similar al del usuario es de suponer que es interesante para él. Esta es la forma sencilla de resolver el tipo de recurso. Una forma más elaborada implicaría que el recurso estuviera anotado semánticamente por medio de una ontología, y el usuario estuviera interesado en los conceptos que trate.
  • Complementando el anterior, la elección del recurso más apropiado se adapta al nivel o skill del usuario en el área concreta del recurso. Evidentemente esto implica modelar en el recurso el nivel de experiencia recomendado para usarlo, y por otro lado, del usuario se tiene la máxima información posible de su experiencia en todas las áreas.
  • Valor de otros recursos relacionados. Un recurso nuevo no ha sido valorado ni usado, por lo que no pueden aplicarse los criterios no contextuales. Sin embargo, si procede de un autor con otros recursos que si que están bien valorados, aumenta su valor.
  • Conjunto de recursos que el usuario tiene en su entorno personal. De este conjunto de recursos es posible aprovechar mucha información:
    • Si el usuario ya está usando un recurso similar que cumpla la misma funcionalidad, el recurso se muestra si es mejor que los que ya tiene, y en caso contrario desciende en la lista de resultados.
    • Si el usuario está usando un recurso compatible con alguno de los buscados o que tiene entradas o salidas compatibles, éste se muestra primero. Este criterio ha de aplicarse mucho más habitualmente en la recomendación de recursos. Al añadir un recurso, se recomiendan los compatibles.
  • Perfil de otros usuarios, con respecto al propio: Los perfiles de los usuarios pueden ser similares, la medida de similitud más sencilla de implementar es la basada en el conjunto de etiquetas usadas. Por tanto, en una búsqueda, son prioritarios los resultados que estén siendo usados por usuarios con un perfil similar al que realiza la búsqueda.
  • Reputación de los usuarios: es posible considerar la noción de reputación de usuarios. Se devuelven primero los recursos utilizados por usuarios con reputación alta, así como aquellos desarrollados o incluidos en el catálogo por desarrolladores de buena reputación.
  • Comunidad del usuario: además de la coincidencia de perfiles, el catálogo cuenta con comunidades de usuarios explícitas, por ejemplo, expertos en Web 2.0. Para un futuro queda la línea de investigación de generación automática de comunidades en base a perfiles similares. En cualquier caso, se puede aprovechar la pertenencia de un usuario a una comunidad de distintas maneras:

NOTA - Pasar la linea futura de investigación al 1.1.3

• • • Los miembros de una comunidad pueden desarrollar o incluir recursos en el catálogo. Estos recursos son prioritarios si aparecieran como resultado de una búsqueda que realice un usuario perteneciente a dicha comunidad.
    • Se tienen en cuenta los recursos usados por miembros de las comunidades a las que un usuario pertenezca.

Descubrimiento de recursos basado en el contexto

En el caso del descubrimiento de recursos, la solución es similar al proceso de búsqueda. La herramienta considera las mismas características y ofrece al usuario los recursos más relevantes, sin que éste haya buscado nada. El funcionamiento es parecido al de un sistema de recomendación.

D 4.1.4 Protocolos de comunicación para transmitir el contexto

A lo largo del presente documento se ha utilizado el contexto de usuario de manera global. Sin embargo, éste está compuesto por información muy heterogénea y sensible. La Ley Orgánica de Protección de Datos^[6] impide compartir y utilizar información personal sin el consentimiento explicito de la persona. El contexto define al usuario mediante características del mismo muy personales y privadas, de las cuales la plataforma conoce algunas de manera anónima, otras que se almacenan en el cliente y otras que se almacenan en el servidor. Por todo ello, no es posible utilizar de manera libre todo el conocimiento acerca de un usuario y es preciso desarrollar con cuidado los protocolos de transmisión de información sensible.

En este entregable se determina el proceso de transmisión de contexto entre el cliente y el servidor. Para ello, primero se estudian diversos protocolos de transmisión de datos y arquitecturas distribuidas, centrándose fundamentalmente en los protocolos de transmisión de contenidos existentes en la Web. Dado el estado del proyecto, se deja como línea futura el diseño del protocolo de transmisión del contexto.

Análisis de arquitecturas y protocolos de comunicación/sindicación de contenidos

Análisis de arquitecturas cliente/servidor Web basadas en el protocolo HTTP)

A continuación se detallan las principales posibilidades de transmisión de contenidos utilizando el protocolo HTTP. Dado que EzWeb es una aplicación Web, es lógico considerar como una opción prioritaria transmitir el contexto mediante el protocolo HTTP. En este caso la información de contexto viaja junto con la aplicación y los datos de la misma, simplificando el proceso. Obviamente usar una arquitectura cliente/servidor tiene desventajas como que la comunicación siempre ha de iniciarla el cliente y el servidor en ningún caso puede pedirle datos. Una arquitectura por pares (P2P), podría ser más útil, pero complicaría la arquitectura global del sistema, e impediría satisfacer uno de los requisitos principales de EzWeb: obtener una funcionalidad total mediante el uso de un navegador Web únicamente.

Servicios Web

Un Servicio Web^[7] o Web Service es una colección de protocolos y estándares que sirven para intercambiar datos entre aplicaciones. Según la W3C es un sistema software diseñado para soportar interoperabilidad máquina a máquina en una red. Frecuentemente son simplemente APIs que son accesibles en una red como Internet, y ejecutadas en un sistema remoto que aloja los servicios solicitados. Distintas aplicaciones de software desarrolladas en lenguajes de programación diferentes y ejecutadas sobre cualquier plataforma pueden utilizar los servicios web para intercambiar datos de manera distribuida. La interoperabilidad se consigue mediante la adopción de estándares abiertos. Las organizaciones OASIS y W3C son los comités responsables de la arquitectura y reglamentación de los Servicios Web. Para mejorar la interoperabilidad entre distintas implementaciones de Servicios Web se ha creado el organismo WS-I, encargado de desarrollar diversos perfiles para definir de manera más exhaustiva estos estándares. Los Servicios Web son el núcleo de las Arquitecturas Orientadas a Servicios (SOA). SOA proporciona una metodología y un marco de trabajo para documentar las capacidades de negocio y puede dar soporte a las actividades de integración, consolidación y sobre todo comunicación. En un ambiente SOA, los nodos de la red hacen disponibles sus recursos a otros participantes en la red como servicios independientes a los que tienen acceso de un modo estandarizado. A la hora de diseñar y desarrollar un sistema basado en esta arquitectura, han de seguirse una serie de principios o recomendaciones que definen las reglas básicas para el desarrollo, mantenimiento y uso de SOA:

• Reutilización, granularidad, modularidad, componibilidad, división en componentes e interoperabilidad.
• Cumplimiento de los estándares, tanto comunes como específicos del dominio).
• Identificación de servicios y categorización, aprovisionamiento y entrega, y monitorización y seguimiento.

Además de lo anterior se detallan una serie de principios arquitectónicos específicos para el diseño y la definición de servicios, centrándose en asuntos que influyen en el comportamiento de un sistema y el estilo del diseño del mismo:

• Encapsulación de servicios.
• Bajo acoplamiento entre servicios: Los servicios han de mantener una relación que minimice dependencias y que consista únicamente en un conocimiento básico de los demás.
• Contratos de servicio: Los servicios han de adherirse a un acuerdo de comunicación, definido colectivamente en uno o varios documentos de descripción de servicio.
• Abstracción del servicio: Más allá de lo que esté descrito en el contrato de servicio, los servicios han de ocultar su lógica de funcionamiento hacia el exterior.
• Reutilización de servicios: La lógica se divide en servicios con el objetivo de facilitar la reutilización.
• Composición de servicios: Una colección de servicios pueden ser coordinados y conectados para constituir servicios complejos.
• Autonomía de servicios: Los servicios han de tener control sobre la lógica que encapsulan.
• Servicios sin estado: Los servicios minimizan la conservación de la información propia de una actividad.
• Facilidad de descubrimiento de servicios: Los servicios se diseñan para ser lo suficientemente descriptivos de forma que puedan ser encontrados y accedidos mediante mecanismos de descubrimiento.

Para la transmisión del contexto en EzWeb, podrían usarse Servicios Web invocados desde el cliente para enviar datos o recibirlos. El problema de esta opción radica en la dificultad de construir las peticiones SOAP utilizando javascript u otra tecnología cliente. Los Servicios Web son demasiado rígidos y más útiles en arquitecturas distribuidas, ya que suelen utilizarse desde el lado servidor, para comunicar una aplicación con otra.

REST

REST (Representational State Transfer)^[8] es un estilo arquitectónico que puede utilizarse para guiar la construcción de servicios Web ligeros, así como protocolos de aplicación con propiedades Web-like. REST queda definido por cuatro restricciones de interfaz: identificación de recursos, manipulación de recursos mediante representaciones de éstos, mensajes auto-descriptivos, e hipermedia como motor del estado de la aplicación: La aplicación cliente cambia de estado con cada representación de recurso manipulada.

Como sucede con otros estilos arquitectónicos como cliente-servidor, REST no representa ningún estándar ni supone ninguna especificación. Tan sólo se puede entender su motivación, asimilar su filosofía y sus principios y diseñar las aplicaciones en ese estilo. REST no es por tanto un estándar, pero sí se basa en estándares como HTTP, URL, XML, XHTML, GIF, JPEG, y tipos MIME. REST tampoco implica ningún detalle de implementación como uso de servlets, OO, CGI o Perl.

REST evoca el comportamiento de una aplicación Web bien diseñada como una red de páginas web en la que el usuario "navega" a través de una aplicación seleccionando enlaces, que resultan en la transferencia de la siguiente página y su visualización. Una analogía de una aplicación REST sería una máquina de estados virtual donde los enlaces son transiciones de estado y las distintas páginas son estados de la aplicación.

Los servicios Web REST siguen una SOA basada en el concepto de "recurso" (URI). La finalidad de REST es exponer recursos a través de URIs y HTTP, no servicios a través de interfaces de mensajería. No debe por tanto confundirse con otros protocolos basados en RPC como SOAP O XML-RPC.

REST emplea el protocolo HTTP con sus 4 métodos bien definidos GET POST PUT y DELETE y mensajes autodescriptivos en algún formato Web-like. Hoy por hoy sólo existe un protocolo (HTTP) que soporte la semántica apropiada de manipulación de recursos. Sin embargo, los sistemas basados en REST son realmente independientes del protocolo. Si en un futuro aparece otro, será sencillo conservar el mismo diseño y símplemente soportar la nueva interfaz de protocolo. La mayoría de los mensajes están en XML, estructurado por un schema escrito en un lenguaje de esquemas como XML Schema del W3C o RELAX NG. Los mensajes simples pueden codificarse con URL encoding. Los servicios y los proveedores de servicios deben ser recursos, mientras que un consumidor puede ser un recurso.

Los sistemas basados en REST son fáciles de implementar y tienen muchas propiedades arquitectónicas áltamente deseables: escalabilidad, reutilización, rendimiento, seguridad, fiabilidad y extensibilidad, orientación a la experiencia de usuarios, alta adaptabilidad al procesamiento de máquina, a la vez que facilidad de implementación. Por ejemplo Amazon dispone tanto de interfaces SOAP como REST para sus servicios Web, y el 85% de su utllización es a través de su interfaz REST, [5]). Este éxito se debe en gran parte a la facilidad de invocación más que a la propia implementación o facilidad de implementación de clientes. Es el cumplimiento de estas propiedades el que ha hecho exitosa la Web y deben por tanto guiar su evolución adhiriéndose a los principios REST. Pueden diseñarse servicios REST que funciones óptimamente en el contexto de la Web. Requieren además escaso soporte de infraestructura, aparte de las tecnologías estándar de procesado HTTP y XML.

Las características fundamentales de REST pueden resumirse en:

• Cliente-servidor, con un estilo de interacción basado en pull: consumiendo representaciones pull de componentes.
• Sin estado, de modo que cada petición de un cliente a un servidor debe contener toda la información necesaria para entender la petición. No se puede utilizar ningún tipo de contexto almacenado en el servidor. Esto facilita la distribución del servicio y de la información manejada por el mismo, así como el uso de clusters, etc.
• Cacheable, pues las respuestas deben poder ser etiquetadas como cacheables o no cacheables con el propósito de mejorar la eficiencia de la red.
• Interfaz uniforme, todos los recursos son accedidos con un interfaz generico como es HTTP GET, POST, PUT y DELETE.
• Recursos nombrados. El sistema se compone de recursos nombrados mediante URLs.
• Representaciones de recursos interconectadas, mediante URLs, permitiendo a un cliente transitar de un estado a otro.
• Componentes estratificados en niveles, que permiten el uso de intermediarios tales como servidores proxy, servidores de caché, gateways, etc entre los clientes y los recursos con el propósito de permitir QoS, rendimiento, seguridad, etc.

La opción de REST es la más adecuada para la transmisión del contexto en EzWeb. Toda la arquitectura de la plataforma EzWeb está diseñada siguiendo el estilo arquitectónico de REST, que es lo suficiente flexible como para transmitir el contexto en uno o en otro sentido cumpliendo las restricciones de la arquitectura cliente/servidor. REST también posibilita integrar el contexto en las peticiones de datos de la plataforma y definir el formato de datos del contexto. Este formato puede ser desde uno de propiedades planas, un JSON, o un metalenguaje xml, hasta lenguajes más expresivos como RDF o OWL. De esta forma, partes privadas del contexto podrían permanecer en el cliente, y ser enviadas al servidor después de confirmarlo el cliente mediante una conexión segura como SSL por medio de una petición POST.

RSS

RSS^[9] es parte de la familia de los formatos XML desarrollado específicamente para todo tipo de sitios que se actualicen con frecuencia y por medio del cual se puede compartir la información y usarla en otros sitios Web o programas. A esto se le conoce como redifusión o sindicación.

La sindicación web es una forma de distribución de información mediante la que parte de una página web se pone a disposición para su uso desde otras páginas. Esto puede ser simplemente licenciando el contenido para que puedan usarlo otras personas; sin embargo, en general, la sindicación web se refiere a ofrecer una fuente web desde una página web para proporcionar a otras personas una lista actualizada de su contenido, como por ejemplo, los últimos comentarios en un foro. Esto tuvo su origen en las páginas de noticias y los blogs, pero cada vez se utiliza más para sindicar cualquier tipo de información.

La sindicación no es sólo un fenómeno vinculado a los weblogs, aunque han ayudado mucho a su popularización. Siempre se han sindicado contenidos y se ha compartido todo tipo de información en formato XML, de esta forma se pueden ofrecer contenidos propios para que sean mostrados en otras páginas de forma integrada, lo que aumenta el valor de la página que muestra el contenido y también genera más valor, ya que normalmente la sindicación siempre enlaza con los contenidos originales.

Los programas que leen y presentan fuentes de datos sindicados de diferentes procedencias se denominan agregadores. Los datos se encuentran sindicados en forma de feed como RSS, Atom1 y otros formatos derivados de XML/RDF.

El agregador recoge ese feed con las noticias y muestra las novedades o ediciones que se han producido en ese feed; es decir, avisan de qué noticias o historias son nuevas desde la última lectura. Mediante los agregadores, se demuestra que el navegador web no es el único medio para ver una página web. Mientras que agregadores de RSS, tales como Bloglines, son aplicaciones web, otros son clientes de escritorio, e incluso otros permiten que los usuarios de dispositivos portátiles se suscriban al contenido permanentemente actualizado.

Pero lo verdaderamente importante es que a partir de este formato se está desarrollando una cadena de valor nueva en el sector de los contenidos que está cambiando las formas de relación con la información tanto de los profesionales y empresas del sector como de los usuarios.

RSS es el avance más significativo de la arquitectura básica de la web desde que los primeros hackers se dieron cuenta de que el CGI se podía utilizar para crear sitios web basados en bases de datos. RSS permite que alguien no sólo enlace con una página, sino suscribirse a la misma, con notificaciones cada vez que la página cambia. Rich Skrenta denomina a esto “la web incremental”. Otros lo llaman la “web viva”.

Ahora bien, por supuesto, los “sitios web dinámicos”, sitios web basados en bases de datos con el contenido dinámicamente generado, sustituyeron a las páginas estáticas de la web hace más de diez años. Lo que es dinámico en la web viva no son sólo las páginas, sino los enlaces. Se espera que un enlace a un weblog señale a una página que cambia perennemente, con los enlaces permanentes o permalinks para cualquier entrada individual, y con notificación de cada cambio. Una fuente RSS es, de esta manera, un enlace mucho más fuerte que, digamos un bookmark o un enlace a una página concreta.

RSS ahora se está utilizando no sólo para enviar avisos de nuevas entradas de un blog, sino también para todo tipo de actualizaciones de datos, incluyendo las cotizaciones en bolsa, información metereológica, y la disponibilidad de fotos. Este uso es realmente un retorno a una de sus raíces: RSS nació en 1997 de la confluencia de la tecnología “Really Simple Syndication” de Dave Winer, utilizada para informar de actualizaciones de blog, y de “Rich Site Summary” de Netscape, que permitió que los usuarios crearan home pages personalizadas en la web de Netscape con flujos de datos actualizados regularmente. Netscape perdió interés, y la tecnología fue continuada por el pionero del blogging Userland, de la compañía de Winer. En el grupo de aplicaciones actuales, podemos apreciar, no obstante, la herencia de ambos padres.

El acrónimo RSS, por tanto, se usa para los siguientes estándares:

• Rich Site Summary (RSS 0.91) Introducido por Netscape.
• RDF Site Summary (RSS 0.9 and 1.0).
• Really Simple Syndication (RSS 2.0), de Dave Winer.

En el sentido más estricto, los RSS siguen la arquitectura REST, que dice que cada recurso tiene una URI, accesible mediante GET y con un formato de datos bien definido. La limitación clara que aparece es que sólo sirve para recuperar información del servidor, no es posible enviar. Sin embargo, podría ser una buena opción que el servidor ofreciera ciertos datos del contexto, como datos anónimos y públicos o estadísticas de uso, como feeds RSS. De hecho, si se opta por la opción de REST para transmitir el contexto, es una posibilidad real ofrecer RSS como formato de representación de recursos.

XML-RPC

XML-RPC es un protocolo de llamada a procedimiento remoto (RPC) que usa XML para codificar los datos y HTTP como protocolo de transmisión de mensajes. ^[10] Como puede observarse, es una filosofía muy cercana a las ideas de los Servicios Web o REST.

Es un protocolo muy simple y, a diferencia de REST, define unos cuantos tipos de datos y comandos útiles, además de una descripción completa de corta extensión. La simplicidad del XML-RPC está en contraste con la mayoría de protocolos RPC que tiene una documentación extensa y requiere considerable soporte de software para su uso. Al igual que REST, es más sencillo que los Servicios Web, pero sin embargo, REST es mucho más flexible ya que no limita el modelo de datos, y a la vez más interoperable ya que aprovecha los verbos HTTP como posibles métodos.

XML-RPC fue creado por Dave Winer de la empresa UserLand Software en asociación con Microsoft en el año 1998. Al considerar Microsoft que era muy simple decidió adicionarle funcionalidades, los cuales después de varias etapas de desarrollo el estándar dejó de ser sencillo y se convirtió en lo que es actualmente se conoce como SOAP. Una diferencia fundamental es que en los procedimientos en SOAP los parámetros tienen nombre y no interesan su orden, no siendo así en XML-RPC.

Entre los tipos de datos disponibles se encuentran tipos de datos simples como enteros y booleanos, y tipos complejos como arrays, fechas, estructuras, datos binarios o el valor null.

Una petición se compone del nombre del método llamado junto con los parámetros, y la respuesta son los datos de salida del método invocado. Como puede observarse, es un comportamiento similar a los servicios basados en SOAP.

Existe una variante de XML-RPC denominada POX-RPC que es más próxima a la filosofía REST. Estos servicios, codifican toda la petición en la URI, indicando en la raiz de la URI el nombre del método a ejecutar, y como parámetros de la URI, los parámetros del método.

Análisis de otras arquitecturas distribuidas

Hasta ahora, se han descrito las distintas posibilidades de transmisión del contexto entre el cliente Web, que comprende la plataforma marketplace y EzWeb, y el servidor, que almacena los datos de la plataforma así como el contexto. En ese escenario, no tiene sentido considerar otra arquitectura distribuida como las que aquí se van a describir. Sin embargo, es posible considerar una arquitectura en la cual alguna de estas tecnologías sea útil: Por ejemplo, existe parte de la información del contexto que se genere en la plataforma EzWeb y parte generada en la plataforma marketplace, la comunicación de dicho contexto de una a otra podría hacerse mediante otro protocolo distinto al HTTP aunque evidentemente este protocolo sea una opción válida. Otra posibilidad es considerar el contexto totalmente distribuido, de forma, que el cliente haga peticiones a un servidor, abstrayéndole de donde está localizado físicamente la información solicitada. Es por ello por lo que se analiza un diseño de arquitectura distribuida (P2P)

P2P

Una red informática entre pares (en inglés peer-to-peer,P2P) se refiere a una red que no tiene clientes ni servidores fijos, sino una serie de nodos que se comportan simultáneamente como clientes y como servidores de los demás nodos de la red. Este modelo de red contrasta con el modelo cliente-servidor utilizado por el ya descrito protocolo HTTP.

Las redes de ordenadores P2P son redes que aprovechan, administran y optimizan el uso de banda ancha entre los usuarios de la red. Estas redes obtienen un mayor rendimiento en las conexiones y transferencias que algunos métodos centralizados convencionales donde una cantidad relativamente pequeña de servidores provee el total de banda ancha y recursos compartidos para un servicio o aplicación. Cualquier nodo puede iniciar, detener o completar una transacción compatible. Típicamente estas redes se conectan en gran parte con otros nodos vía ad hoc.

Dichas redes son útiles para muchos propósitos, pero se usan muy a menudo para compartir y transmitir archivos. En el ámbito del proyecto EzWeb, podría ser interesante generar una red de servidores interconectados utilizando un protocolo P2P

Diseño del protocolo de transmisión del contexto de usuario

En el apartado anterior, se estudiaron las distintas posibilidades para transmitir el contexto. Dada la filosofía del proyecto, y por analogía con decisiones tomadas en otras secciones del mismo, la solución más lógica (y más adecuada) es utilizar una arquitectura REST para la transmisión de los datos del contexto. Para definir una arquitectura REST, hay que realizar los siguientes pasos:

• Definir qué recursos se encuentran en la arquitectura. En este caso concreto, habrá que determinar qué elementos del contexto son recursos, o si todo el contexto puede considerarse como un único recurso. Lógicamente la primera opción parece más lógica, ya que ofrece una granularidad y escalabilidad mayores.
• Una vez identificados los recursos, será preciso determinar sus identificadores (URIs) para poder referenciarlos.
• Hay que describir las distintas representaciones de los recursos, determinando su formato (XML, JSON...) y los distintos elementos que las componen)
• Por último, hay que determinar los métodos de acceso HTTP permitidos para cada recurso, así como la semántica de los códigos de los mensajes HTTP devueltos.

Como en apartados anteriores, dada la fase en la que se encuentra el proyecto, aún no es posible determinar que elementos del contexto deberán ser transmitidos, por lo que no es posible definir el conjunto de recursos (ni URIs, ni formatos, ni métodos de acceso), hasta llegar a acuerdos con respecto al contexto.

Conclusiones y Futuras Mejoras

Conclusiones

En el presente conjunto de entregables se han analizado las distintas posibilidades que puede aportar la noción de contexto en el ámbito de la plataforma EzWeb, dentro de la búsqueda de recursos. Se han dado los primeros pasos para diseñar una arquitectura que permita a la plataforma recomendar a los usuarios los recursos más adecuados para su perfil de usuario y su contexto de ejecución, así como filtrar los resultados de las búsquedas, para devolver al usuario los resultados más adecuados a sus necesidades. Para realizar esta tarea, se han estudiado qué características del contexto son más relevantes en el descubrimiento de recursos y por qué. Posteriormente, se ha descrito el proceso que la plataforma ha de seguir para recomendar al usuario los recursos más adecuados. Por último, se han analizado las distintas posibilidades para transmitir el contexto en el ámbito de la plataforma. Es importante destacar que las posibilidades son muchas cuando se habla de contexto de usuario, e idealmente es posible explotar el perfil de usuario para devolverle únicamente aquello que necesita. Evidentemente, es muy complejo llegar a esa situación, pero en este entregable se han dado los primeros pasos para explotar (aunque sea parcialmente) el contexto de usuario, simplificando sus búsquedas, y en consecuencia, el manejo habitual de la plataforma. Aún así, todavía quedan muchas decisiones que tomar,

Futuras Mejoras

Como se menciona a lo largo del entregable, debido a la fase en la que se encuentra el proyecto, todavía no se ha elegido un motor de reglas ni implementado los mecanismos de creación del contexto de usuario. Por lo tanto, todavía no es posible llegar a un diseño e implementación de la arquitectura que permita recomendar al usuario los recursos que se adapten a su perfil. A pesar de ello, ya se está trabajando en avanzar en la medida de lo posible en este camino. Fundamentalmente, ha de llegarse a un acuerdo (una formalización) del contexto de usuario, qué datos forman parte y cuáles no. Una vez se formalice el contexto de usuario y los mecanismos para crearlo, será posible llegar a una arquitectura detallada del sistema de recomendación. Por otro lado, habrá que definir en detalle el protocolo de transmisión del contexto.

Referencias

1. ↑ Wikipedia. Context Awareness. Available at [1]
2. ↑ Fielding, R.T., Berners-Lee, T. et al. Header Field Definitions, Hypertext Transfer Protocol -- HTTP/1.1 (RFC 2616). Available at [2]
3. ↑ Neches, R. Fikes, R. Finin, T. Gruber, T. Patil, R. Senator, T. and Swartout W.R. Enabling technology for knowledge sharing AI Magazine, 12(3):16-36, 1991.
4. ↑ Forgy, C.L. Rete. A Fast Algorithm for the Many Pattern/Many Object Pattern Match Problem. Artificial Intelligence, 19(1982) 17-37
5. ↑ Granka, L. Joachims, T. and Gay, G. Eye-Tracking Analysis of User Behavior in WWW-Search. Poster Abstract, Proceedings of the Conference on Research and Development in Information Retrieval (SIGIR). (2004)
6. ↑ Ley Orgánica 15/1999, de 13 de diciembre, de Protección de Datos de Carácter Personal. Publicado en BOE núm. 298, de 14-12-1999, pp. 43088-43099
7. ↑ W3C.Web Services Activity Available at [3]
8. ↑ Fielding, R. T. Architectural Styles and the Design of Network-based Software Architectures.Ph. D. Disertation. University of California, Irvine (2000)
9. ↑ Pilgrim, M. What Is RSS O'Reilly (2002). Available at [4]
10. ↑ Laurent, S., Johnston, J., Dumbill, E. (June 2001) Programming Web Services with XML-RPC O'Reilly. First Edition. Foreword by Dave Winer.