D 2.2 Descripción semántica de recursos

De MorfeoWiki

Contenido 1 Resumen y objetivos 2 D 2.2.1 Requisitos, análisis y listado de ontologías para describir los recursos generales de EzWeb 2.1 Recursos en EzWeb 2.2 Claves en la búsqueda de un formalismo 2.3 Soluciones en la web semántica 2.3.1 Análisis de ontologías propuestas en la memoria 2.3.2 Análisis de otras ontologías 2.4 Requisitos 2.5 Análisis de recursos 2.6 Formalización de recursos 2.6.1 Definición formal de componentes 2.6.2 Tipos de variables 2.6.3 Modelo de mashups 2.6.4 Comunicación 2.6.5 Composición 2.6.6 Tipos 2.6.7 Unicidad de nombres 2.6.8 Simplificación automática de mashups y componentes complejos 2.6.9 Semántica "blanda" de componentes 3 D 2.2.2 Análisis, especificación y listado de ontologías para describir contenidos 3.1 Análisis de contenidos 3.2 Formalización de contenidos 3.2.1 Optimizaciones de mashups con contenidos 4 D 2.2.3 Análisis, especificación y listado de ontologías para describir servicios 4.1 Análisis de servicios 4.1.1 Características deseables pero no analizadas 4.2 Formalización de servicios 4.2.1 Operadores 4.2.2 Adaptadores 4.2.3 Descubrimiento automático de adaptadores 4.2.4 Detección de operadores no usados 5 D 2.2.4 Análisis, especificación y listado de ontologías para describir gadgets 5.1 Análisis de gadgets 5.2 Formalización de gadgets 5.2.1 Preferencias 5.2.2 Tamaño de los gadgets 5.2.3 Gadgets con semántica conocida 5.2.4 Optimizaciones y detección de errores 6 Referencias 7 Apéndice: Ontología de recursos EzWeb en OWL

Resumen y objetivos

En el presente documento se recogen los cuatro entregables del paquete de trabajo PT 2.2 cuyos objetivos son:

1. Definir un marco formal para la descripción de recursos dentro del proyecto EzWeb.
2. Formalización de dichos recursos.

El documento se ha estructurado en cuatro secciones además de la presente. En cada una de ellas se recoge uno de los entregables de PT 2.2:

#D.2.2.1 Requisitos, análisis y listado de ontologías para describir los recursos generales de EzWeb

#D.2.2.2 Análisis, especificación y listado de ontologías para describir contenidos

#D.2.2.3 Análisis, especificación y listado de ontologías para describir servicios

#D.2.2.4 Análisis, especificación y listado de ontologías para describir gadgets

En la sección #D.2.2.1 Requisitos, análisis y listado de ontologías para describir los recursos generales de EzWeb se ofrecen definiciones de términos como recurso y sus tipos (contenido, servicio y gadget), se muestran las características más relevantes de los recursos y se discute sobre la selección de un marco de formalización teniendo en cuenta casos de éxito en entornos similares (web semántica y ontologías).

La formalización de los tres tipos de recursos se ha recogido en una ontología desarrollada con la herramienta de software libre Protégé^[1] (versión 4.0) y anexada a este documento como documento adjunto. Las secciones #D.2.2.2 Análisis, especificación y listado de ontologías para describir contenidos, #D.2.2.3 Análisis, especificación y listado de ontologías para describir servicios y #D.2.2.4 Análisis, especificación y listado de ontologías para describir gadgets contienen el análisis y explicaciones sobre la formalización de contenidos, servicios y gadgets.

La información presentada en este documento ha sido publicada en Modeling Mash-up Resources^[1], , Pattern Definitions and Semantically Annotated Instances ^[1], y Gadget composition and automatic discovery in EzWeb^[1] como parte de las actividades de difusión del proyecto.

D 2.2.1 Requisitos, análisis y listado de ontologías para describir los recursos generales de EzWeb

Esta sección arranca con una breve introducción a los recursos en la plataforma EzWeb, las claves que deben tenerse en cuenta en la selección de un formalismo y una referencia a las soluciones adoptadas para especificar elementos dentro de la web semántica al considerar que los objetivos del proyecto están alineados con los objetivos que persigue la web semántica. Termina el documento con un análisis de los requisitos de los recursos que se van a formalizar y una muestra de componentes básicos en dicha formalización.

Recursos en EzWeb

El concepto de recursos en la plataforma EzWeb resulta ser una capa de abstracción sobre la representación interna de contenidos y servicios así como sobre su posible representación gráfica en forma de gadgets. A continuación se recogen las características que se han considerado fundamentales de la memoria del proyecto:

• Cuando un recurso ofrece acceso a fuentes de datos externas permitiendo su consulta o modificación, nos encontramos ante un tipo de recurso denominado contenido^[1].
• Cuando un recurso realiza un procesamiento de información obtenida de otros recursos, nos encontramos ante un tipo de recurso denominado servicio^[1]. Los servicios puede clasificarse en servicios de back-end y operadores, los primeros abstraen la plataforma del acceso a servicios externos (probablemente legados o accedidos mediante servicios web), los segundos simplemente transforman los datos de otros recursos.
• Cuando un recurso produce información que puede ser integrada directamente en el interfaz de usuario y proporciona una representación gráfica de dicha información, nos encontramos ante un tipo de recurso denominado gadget^[1].
• En la memoria del proyecto se sugiere^[1] una línea en la semántica de los recursos, al ser definidos como componentes software que siguen el paradigma REST (Representational State Transfer ^[1][1]): cada recurso tiene un URI (Uniform Resource Identifier) y admite cuatro operaciones básicas (GET, POST, PUT y DELETE). Para atender las peticiones, los recursos encapsulan el acceso a información o incluso a otros recursos, reunen los resultados de dichos accesos, opcionalmente los procesan, y entregan nuevos datos a otros recursos o incluso al usuario final.
• Como en cualquier otra plataforma de mashups, los recursos pueden ser fabricados por composición de otros recursos existentes en el sistema por lo que el marco formal debe recoger al menos un concepto de composicionalidad.
• La fabricación de recursos por composición debe ser accesible al usuario final de una forma sencilla utilizando conceptos como piping que deberán descansar sobre la composicionalidad de recursos.

La interpretación de estas características no es única y dentro del equipo que desarrolla la plataforma existen tantas interpretaciones y enfoques como partners participan en el proyecto. En este documento se han analizado diferentes puntos de vista y se ha intentado sacar un factor común de todos ellos (ver sección #Requisitos).

Además de las características declarativas o funcionales de los recursos, hay otros aspectos que capturar, como el vendor, el autor, la fecha de creación, el gráfico de presentación en el catálogo, etc. Aunque los usuarios pueden querer hacer búsquedas utilizando estos criterios, la funcionalidad proporcionada por un recurso no depende de esa información.

Basándonos en esta distinción, se ha decidido dividir la semántica a capturar en dos niveles:

• Semántica dura: captura características funcionales del recurso, es decir, aquellas que influyen en los resultados que se obtienen en su ejecución.
• Semántica blanda: captura características no funcionales, que pueden ser útiles para relacionar recursos (sin usar información declarativa) o para cierto tipo de búsquedas, para la integración con la información del contexto (D 2.1 Descripción semántica del contexto) y con folksonomías (D 2.3 Integración de folksonomías y ontologías).

Claves en la búsqueda de un formalismo

A continuación se señalan los puntos clave en la búsqueda de marcos formales candidatos para describir recursos en la plataforma:

• Las características de contenidos, servicios y gadgets pueden llegar a ser muy diferentes por lo que no debe descartarse el uso de diferentes formalismos.
• Los recursos, de diferente o de mismo tipo, pueden ser compuestos unos con otros por lo que es necesario seleccionar formalismos cuya integración no sea complicada.
• El razonamiento sobre los recursos y la extracción automática de información es un principio fundamental de la plataforma, por ello, sobre dichos formalismos deben existir motores de razonamiento y lenguajes de consulta (query languages).
• Debe existir un equilibrio entre la expresividad de los formalismos elegidos, su complejidad desde la perspectiva de usuarios no necesariamente expertos en especificaciones formales y su nivel de automatización.
• Los recursos son ubicuos en toda la plataforma EzWeb y cada módulo de la misma los entenderá de diferentes formas. Su formalización debe adaptarse a los usos más relevantes.
• Deberá permitirse que un recurso sea configurable en tiempo de ejecución, es decir, que existan parámetros del recurso que el usuario de la plataforma pueda establecer pero que tengan unos valores dados por defecto.

Tanto desde IMDEA como desde Fundación CTIC se considera que existen más ventajas que inconvenientes en que el formalismo para la descripción de recursos sea el mismo independientemente del tipo de recursos, a no ser que se demuestre lo contrario por falta de expresividad o por un aumento de la complejidad en la semántica.

Soluciones en la web semántica

En esta sección se realiza un resumen de los elementos de la web semántica que interesa explorar a la hora de formalizar los recursos de la plataforma. Se puede encontrar una descripción detallada de dichos elementos en D.2.1 Descripción semántica del contexto#Representación de conocimiento en la Web Semántica.

Los objetivos del proyecto están alineados con los objetivos de la web semántica^[1]: "conseguir que la web entienda las necesidades de personas y máquinas en el uso del contenido de la misma".

Los recursos de la plataforma pueden considerarse elementos de la web semántica y, por tanto, aquellos formalismos utilizados en la web semántica son los primeros candidatos a la hora de especificar los recursos EzWeb.

La viabilidad práctica de la web semántica se pone continuamente en duda. Sin embargo, muchos de sus elementos ya han sido expresados formalmente utilizando lenguajes de modelado de información. RDF (Resource Description Framework^[1]) es su principal caso de éxito y sobre dicho marco se ha construido una torre de lenguajes y metalenguajes para inyectar semántica en la web.

RDF y sus formatos de intercambio^[1] han evolucionado hacia lenguajes más abstractos para la descripción de datos y recursos de los que destacan los lenguajes para la definición de ontologías^[1] como OIL (Ontology Inference Layer^[1]), DAML+OIL (DARPA Agent Markup Language + OIL^[1]), RDFS (RDF Schema^[1]) y OWL (Ontology Web Language^[1]).

El uso de ontologías para caracterizar recursos parece una decisión poco discutible tanto en la web semántica como en este proyecto, más si se tiene en cuenta el trabajo previo realizado en la memoria del proyecto.

La elección de un metalenguaje concreto (RDF, OIL, DAML-OIL, RDFS, OWL, etc.) para la definición de las ontologías que formalicen los recursos es un trabajo complejo. Por un lado, dicha elección no influirá en la descripción de los modelos ontológicos pero, por otro lado, el uso eficaz y extenso que se haga o deje de hacerse en la práctica dependerá de dicho lenguaje.

A estas alturas del proyecto creemos que OWL es la opción más prometedora para realizar las especificaciones de los recursos, por las razones a continuación:

1. OWL y RDFS son los lenguajes más extendidos para describir ontologías en la web.
2. OIL y DAML+OIL quedarían descartados, por ser lenguajes desfasados cuya evolución ha dado como fruto OWL.
3. RDF es el lenguaje sobre el que se construyen el resto de opciones. Su uso en crudo quedaría descartado puesto que su semántica tiene poca estructura y obligaría a introducir innumerables aserciones para capturar información similar a la que ya capturan RDFS o OWL.
4. Sobre RFDS hay dudas^[1] sobre lo adecuado que es más allá de como lenguaje de metadatos.
5. La sintaxis normativa de OWL es RDF/XML, lo que permite la incorporación automática de vocabularios para la descripción de datos como RDFS o Dublin Core (ver #Análisis de ontologías propuestas en la memoria).
6. OWL tiene asociados lenguajes de razonamiento y de interrogación suficientemente contrastados, como pueden ser KAON2^[1] y OWL-QL^[1].

La conclusión final es que OWL es nuestra elección más natural, más precisamente OWL 2 ya que su semántica se corresponde con una lógica descriptiva bastante expresiva y con importantes resultados sobre su decidibilidad (criterio importante al incluir razonadores).

Análisis de ontologías propuestas en la memoria

En la memoria del proyecto se señalan las siguientes propuestas para ser analizadas como base fundamental de la ontología que permita describir recursos, principalmente contenidos, de la plataforma: SIOC^[1], FOAF^[1], SKOS^[1], Dublin core^[1].

A continuación se ofrece una breve descripción de cada uno de estos vocabularios junto con un análisis sobre su posible uso en la formalización de los recursos:

• SIOC es una ontología que captura la semántica de los diferentes métodos de discusión que pueden encontrarse en la red como son blogs, forums, grupos de news o simplemente listas de correo electrónico. El lector puede encontrar una descripción más detallada de esta ontología en D.2.1 Descripción semántica del contexto#Contexto y perfil de usuario.

Análisis:

• Cuando la fuente de información de un recurso EzWeb, especialmente un contenido, sea un método de discusión (o un concepto dentro de un método de discusión), es probable que parte de dicho recurso pueda formalizarse con vocabulario SIOC.
• Aunque en la versión inicial de la ontología que se proponga para la semántica de los recursos no se llegue a capturar información de este tipo, sería posible hacer un enlace con ciertos conceptos de SIOC que serían útiles para realizar búsquedas en EzWeb. En caso de que finalmente existiese esa unión, podría capturar aspectos de semántica dura.

• FOAF es una ontología que permite capturar información sobre personas y, más importante, de relacione entre dichas personas. El lector puede encontrar una descripción más detallada de esta ontología en D.2.1 Descripción semántica del contexto#Contexto y perfil de usuario.

Análisis:

• El vocabulario FOAF puede servir para capturar relaciones entre creadores o vendedores de recursos, y también para capturar relaciones entre usuarios que ejecutan los recursos en su entorno operacional. A este nivel sólo se representaría el primer caso como parte de la semántica blanda, y ambos aspectos deberán ser tenidos en cuenta con mayor detalle en D 4.1 Técnicas de descubrimiento de recursos en función del contexto.

• SKOS es simplemente un vocabulario RDF que permite capturar información sobre conceptos (unidades de pensamiento), etiquetas (palabras) que se asocian a conceptos, y relaciones entre dichos elementos.

Análisis:

• Lo excesivamente abstractos y difusos de los elementos que se pueden representar con SKOS nos hace pensar que dicho vocabulario queda fuera del alcance de la semántica de recursos EZWeb.

• Dublin Core es una ontología estándar ampliamente utilizada para describir material digital como video, sonido, imágenes, texto y páginas web, entre otros. Entre otros elementos semánticos que puede capturar Dublin Core se encuentran creadores de los recursos, fechas de creación, derechos de autor, etc.

Análisis:

• Al igual que en el caso de FOAF, Dublin Core podría ser útil para modelizar ciertos aspectos de semántica blanda, como los creadores de los recursos, vendors, las relaciones entre ellos, fechas de creación, etc. De esta forma se enlazarían distintos aspectos de la modelización de recursos en EzWeb y se daría soporte a más capacidades para la búsqueda y el descubrimiento de recursos relacionados.

Análisis de otras ontologías

La proliferación de ontologías para representar conocimiento hace que tengamos a nuestra disposición innumerables formalizaciones de vocabularios con elementos semánticos compatibles con la semántica de los recursos EzWeb. Desde nuestro punto de vista, la clave no es si es posible llegar a describir la semántica de cualquier recurso utilizando ontologías existentes si no si es recomendable. Veamos un análisis de las principales ventajas y desventajas de usar ontologías existentes:

• Ventajas: se reusan conceptos ya definidos, en principio se tiene la garantía de tener formalizaciones contrastadas y se favorece la comunicación de información y la compatibilidad con otros grupos de desarrollo.
• Desventajas: el uso de otras ontologías puede complicar excesivamente la semántica de los recursos al importar elementos semánticos con excesiva complejidad, poco adecuados en la plataforma EzWeb o incluso con errores.

Teniendo en cuenta las observaciones expuestas, se ha decidido utilizar como criterio que, cuando haya un único concepto o clase que tenga un nexo con otras formalizaciones, se defina un elemento propio en EzWeb que capture esa información. Más adelante podrá establecerse un concepto de EzWeb como sinónimo de un concepto de otra ontología si se pretende explotar los resultados de otros formalismos. Esto nos permite ceñirnos a los aspectos que queremos modelizar sin que se vea comprometida la reusabilidad de nuestro modelo.

Algunos criterios de busqueda de ontologías que deberán ser analizadas son:

• Información de tipos de datos: la ontología debe permitir capturar conocimiento acerca de los tipos de los datos de entradas y salidas de los recursos, de forma que se pueda comprobar la compatibilidad entre ellos.
• Composicionalidad: La ontología debe permitir capturar, además, la composición de recursos, el uso de unos recursos por parte de otros y garantizar la compatibilidad interna entre los componentes.
• Interfaz de usuario: a este nivel es necesario capturar no sólo información de la interfaz gráfica (como pueden ser los tamaños mínimos de la interfaz o la profundidad de color necesaria), sino también información relativa a otros dispositivos de los que el recurso haga uso, como pueden ser micrófono, webcam, lector de huella digital, etc.

Requisitos

En esta sección se ha analizado el resultado previo de otros paquetes de trabajo del proyecto así como alguna propuesta realizada desde otros proyectos para buscar un conjunto de requisitos fundamentales en la plataforma. La lista de documentos estudiados es la siguiente:

• La memoria del proyecto.
  • Resultados: un resumen de requisitos se ha ofrecido en la sección #Recursos en EzWeb.

• Desarrollo de Modelos de Procesos
  • Versión wiki, probablemente desactualizada, del entregable del proyecto Plataforma SMARTFlow (PROFIT FIT-350400-2006-23). En él se define un modelo de coreografía de recursos.
  • Resultados: se recomienda un modelo de comunicación entre recursos basado en un mecanismo de paso de mensaje que fluyen desde un recurso a otro con puntos de salida denominados eventos y puntos de entrada denominados acciones y se recomienda el uso de arquitectura REST.

• http://morfeo.yaco.es/ezweb-a3/wiki/Template
  • Documento que recoge detalles de implementación de los gadgets a nivel de su posible participación en el intercambio de datos con otros gadgets.
  • Resultados: los gadgets tendrán que reflejar la existencia de variables que permitan su configuración por parte del usuario en el momento de usarlos, de nuevo aparecen los puntos de salida denominados eventos y los puntos de entrada denominados slots. Nos preocupa especialmente la complejidad del significado que puede tener un sistema de envio y recepción de mensajes (eventos/slots) mezclado, como se sugiere, con un sistema de compartición de variables (las distintas ocurrencias de gadgets tienen acceso a variables internas de otros gadgets).

• http://morfeo.yaco.es/ezweb-a3/wiki/Paleta_Personal y http://morfeo.yaco.es/ezweb-a3/wiki/Persistencia
  • Documentos que describen la paleta personal de gadgets de un usuario y la persistencia de las ocurrencias de gadgets.
  • Resultados: ambos documentos están incompletos y no es posible extraer información sobre los requisitos de los recursos. En cualquier caso es probable que una vez determinadas las características de ambos módulos deban incluirse nuevos elementos en la formalzación de recursos que debe salir del grupo de entregables de PT 2.2.

• http://morfeo.yaco.es/ezweb-a3/wiki/Arquitectura%20y%20Dise%C3%B1o%20de%20Wiring y http://morfeo.yaco.es/ezweb-a3/wiki/GadgetsModel
  • Éste es probablemente uno de los documentos con más información concreta sobre requistos de los recursos, gadgets en particular.
  • Resultados: aunque el sistema de wiring de la plataforma se encarga de la interconexión de gadgets y en ningún momento se habla del resto de recursos, se ha considerado que en el nivel de descripción de recursos debe seguirse una filosofía similar a la de wiring, y viceversa. De nuevo aparecen conceptos como eventos, slots y canales de comunicación y se ha intentado garantizar la reusabilidad de los esfuerzos realizados en ambas partes del proyecto. Se ha respetado, hasta donde ha sido posible la semántica de comunicación entre gadgets como semántica de comunicación entre recursos.

• http://morfeo.yaco.es/ezweb-a3/wiki/Catalogo
  • En el catálogo están los recursos asi que su diseño debe capturar un modelo de datos de los recursos.
  • Resultados: el modelo de datos del catálogo debe incorporarse a la formalización de recursos en los entregables de PT 2.2. Sin embargo, dicho modelo de datos es bastante estático y relativamente sencillo por lo que puede ser incorporado para completar la formalización en cualquier momento y no se ha realizado un esfuerzo más allá que el de reflejar aspectos fundamentales o especialmente dificultosos.

• D.3.2 Documento de definición de modelos avanzados de comunicación y composición de recursos
  • Se recoge un análisis de varios mecanismos de comunicación utilizados en el contexto web.
  • Resultados: no se ofrece una propuesta clara con respecto al mecanismo de comunicación entre recursos dentro de la plataforma.

• D.4.1 Técnicas de descubrimiento de recursos en función del contexto#Características del contexto relevantes en el descubrimiento de recursos
  • Se ofrecen características relevantes del contexto para el descubrimiento de recursos.
  • Resultados: los elementos resaltados en dicha sección deberán, probablemente, ser capturados en la formalización de los recursos, sin embargo, debemos manternos a la espera de los resultados de PT 2.1 (ver D.2.1 Descripción semántica del contexto) y PT 2.3 (ver D.2.3 Integración de folksonomías y ontologías) puesto que el descubrimiento de recursos puede ser más eficiente mediante el uso de las folksonomías.

Además de requisitos educibles de los resultados de documentos citados, existe una serie de requisitos adicionales que deberán ser estudiados. A continuación se da una lista de requisitos que no se han podido confirmar o descartar completamente, y que deberán ser estudiados a medida que avance el proyecto.

• La descripción semántica de los recursos debería permitir saber la compatibilidad entre recursos, permitir recuperarlos de una forma más eficiente y poder establecer relaciones con información del contexto del usuario. Esto muestra que el Template y el Catálogo están profundamente relacionados con la descripción de los recursos, y deben tenerse en cuenta para determinar la semántica de EzWeb.

• Los servicios podrían ser forzados a seguir el paradigma REST. En la memoria del proyecto se indica que los recursos usan REST, dejando como decisión posterior si debe utilizarse para el acceso a recursos externos o también en el acceso al catálogo u otras funciones. Aunque actualmente no se incluye información específica de acceso REST en la ontología excepto para contenidos, en el futuro podría ser capturado en el modelo de forma específica para todos los recursos. En dicho caso sería conveniente analizar en los siguientes formalismos para realizar el modelo (algunas referencias son realmente marginales):
  • Ontologías para especificar servicios web como WSMO^[1] o OWL-S^[1].
  • Lenguajes para especificación de servicios web basados en arquitectura RESTful como WRDL^[1], Resedel^[1], WADL^[1], SMEX-D^[1]
  • Otros lenguajes, quizá más complejos, para especifcar servicios web: WSDL v2.0^[1], WSML^[1], RDF-Forms^[1].

• Los gadgets podrían interpretarse como servicios con una interfaz gráfica asociada. Para capturar la información relativa a interfaz gráfica se puede utilizar cualquier formato XML que describa interfaces gráficos (como XUL^[1] o el formato usado en Qt^[1]). Aunque dichos formatos no permitan capturar todo lo necesario a nivel de interfaz y puede que sea demasiado potente para lo que se busca, puede ser una buena fuente en la que basarse a la hora de diseñar un formalismo específico para EzWeb.

Análisis de recursos

De la lectura de la sección anterior se hace patente que diferentes partes del proyecto tienen concepciones diferentes de lo que son los recursos. Desde IMDEA se ha considerado que la formalización de los recursos en EzWeb no debía ser realizada en el aire y utilizando lenguaje natural. La decisión tomada ha sido formalizar los recursos como una ontología descrita en OWL.

Sin entrar en los detalles de formalización de cada tipo de recurso, la ontología debería capturar el conocimiento general dado a continuación. Cada punto se ha acompañado con las clases y propiedades relacionadas. En la siguiente sección se presentará la formalización en mayor detalle.

• En todos los documentos consultados excepto en la implementación de recursos, se utiliza el término recursos para referirse a veces a la definición de un recurso, a veces a la existencia de un recurso en la ejecución de la plataforma. Dentro de la ontología deberían recogerse los dos conceptos por separado: definición de recursos y ocurrencia de recursos. Además, existen dos niveles de ocurrencia de recursos: como parte de la definición de un recurso compuesto, y como recurso en ejecución. A nivel de nuestro modelo, dividiremos la formalización en dos ontologías: una para las definiciones, y una para las ocurrencias. Excepto cuando sea evidente por el contexto, prefijaremos todos los conceptos y relaciones con el espacio de nombres def, cuando corresponda a un elemento del nivel de definiciones de componentes, y occ, cuando corresponda al nivel de ocurrencias de recursos como parte de un mashup (en tiempo de diseño o ejecución).

• Debido a la confusión a la que puede llevar el uso de la palabra recurso (por su generalidad), hemos optado por usar la palabra componente, más cercana al campo de software basado en componentes, altamente relacionado con la plataforma que intentamos modelizar. Clases: def:Component.

• Cada definición de recurso tiene asociada una URI interna a la plataforma. Esta URI vendrá determinada por el nombre del recurso, su identificador interno en la plataforma, y el sistema en el que sea implementada, por lo que no se incluye de forma explícita como una propiedad de los recursos en nuestro modelo.

• Los componentes tienen variables, entre las que estaremos especialmente interesados en las variables de comunicación. Las variables tienen un nombre, y es único por cada componente (dos variables pueden tener el mismo nombre, pero no dos variables que pertenezcan al mismo componente). Pueden ser de lectura o de lectura/escritura. Clases: def:Variable, def:CommVariable, def:ReadOnly_Variable, def:ReadWrite_Variable. Propiedades: def:var_def_in_comp.

• Los componentes envían mensajes (también denominados eventos o señales) a través de puntos de salida que se han denominado events en la ontología. Clases: def:Event.

• Los componentes reciben mensajes a través de puntos de entrada denominados slots en la ontología. Clases: def:Slot.

• Los componentes pueden salvar su estado interno en variables de estado. Esto permite recuperar el estado de ejecución si el usuario reinicia su sesión o la abre desde otro terminal. Clases: def:StateVariable.

• Los componentes pueden acceder a propiedades de la plataforma a través de variables de contexto de plataforma. En ellas pueden consultar el idioma de la plataforma y el usuario que está ejecutando la sesión. Clases: def:ContextVariable, def:PlatformContextVariable.

• Todos los datos intercambiados en la plataforma deben estar tipados (esto ayudarán tanto a evitar errores en tiempo de ejecución como al descubrimiento de componentes y a sugerir a usuarios menos experimentados puntos de conexión entre componentes). Una decisión que podría tomarse es hacer pertenecer cualquier definición de datos a un concepto Type de la ontología que, en el futuro, podrá crear una jerarquía que permita describir los datos como tipos básicos, esquemas de datos más complejos (DTDs o XML Schemas) o incluso ontologías como FOAF, DOAP, etc. Nótese que, aunque a nivel de diseño y ontología los datos tengan que tener un tipo, la plataforma no tiene por qué comprobar, en tiempo de ejecución que estos tipos se respetan. Eso es especialmente difícil (y computacionalmente, más costoso de lo que se podrá asumir) en lenguajes como Javascript, que usa un sistema de objetos basado en "duck typing" (si se comporta como un tipo concreto, podemos usarlo como tal). Clases: type:Type. Propiedades: def:has_type, type:is_subsumed_by.

• Además, se permite crear una coreografía de recursos, lo que se conoce como mashup. Un mashup es simplemente una colección de ocurrencias de componentes. Clases: occ:Component, occ:Mashup. Propiedades: occ:occ_def_by, occ:composed_by.

• Las ocurrencias de componentes pueden estar conectadas mediante canales de comunicación. Las ocurrencias de slots conectadas a un canal reciben datos que se envíen a él. Las ocurrencias de eventos conectadas a un canal pueden enviar datos al mismo. Cada ocurrencia de recurso tendrá asociada una definición, y tendrá una ocurrencia de variable de comunicación para cada variable que tuviera en su definición. Clases: occ:CommVariable, occ:Event, occ:Slot, occ:Channel. Propiedades: occ:var_def_by, occ:var_occ_in_comp, occ:var_occ_linked_to.

• Podemos definir nuevos componentes por composición de otros. Para ello, debemos especificar qué ocurrencias están en el nuevo componente a definir, e incluir una lista de definiciones de variables, junto con las ocurrencias de variables (internas) con las que se corresponden. También deberemos incluir las propiedades de semántica "débil" descritas para componentes sencillos (autor, versión, etc.). Clases: def:Simple, def:Compound. Propiedades: occ:var_exposed_as.

Es importante, especialmente en puntos posteriores, destacar que la ejecución de recursos ocurre, a efectos del usuario y de composición de recursos, de forma concurrente. Esto implica que, aunque el modelo interno de ejecución de la plataforma sea mediante un único hilo, no existe un orden predefinido de ejcución y dos ejecuciones con los mismos recursos podrían no ser iguales.

Los detalles específicos de los diferentes tipos de recursos se discuten en el resto de entregables.

Formalización de recursos

A continuación se exploran y explican los puntos capturados en la ontología de recursos en mayor detalle.

La formalización en OWL puede ser descargada desde http://babel.ls.fi.upm.es/~iperez/ezweb/ontologies. Sugerimos al lector no familiarizado con ontologías el uso de la herramienta Protégé para su consulta o modificación.

Definición formal de componentes

En este docuemtno utilizararemos la terminología componente en lugar de gadget: la formalización ofrecida abarca un conjunto de gadgets más amplio que aquellos que el usuario final instanciará normalmente en su entorno, incluyendo algunos que están dirigidos a usuarios expertos de la plataforma o incluso desarrolladores de gadgets.

Un componente es, en su definición más sencilla, una "caja" con variables o puertos de entrada y de salida. Estas variables constituyen la interfaz del componente con el mundo exterior, y establecen cómo se comunica con él. Representaremos los componentes, gráficamente, como se muestra en la siguiente figura.

En este ejemplo, a, b y c serían variables, y X sería una definición de un componente. Utilizaremos los conceptos def:Component y def:Variable, respectivamente, para definiciones de componentes y variables. Cada variable pertenece a un componente y sólo a uno. Esta relación se expresa con la propiedad funcional total def:var_def_in_comp, con dominio def:Variable, rango def:Component.

Aunque normalmente evitaremos presentar fórmulas en lógica descriptiva en este documento (el lector que desee profundizar puede dirigirse la la bibliografía), se presentan a modo de ejemplo los siguientes axiomas que expresan, respectivamente, el dominio de la relación, su rango, y que es funcional y total:

⊑ ∀ def:var_def_in_comp¯ . def:Variable

⊑ ∀ def:var_def_in_comp . def:Component

def:Variable ⊑ =1 def:var_def_in_comp .

En la figura incluida más arriba, la relación def:var_def_in_comp se ha representado como la superposición de una caja que representa una variable sobre una caja que representa un componente. Así, tenemos que a def:var_def_in_comp X, o lo que es lo mismo, (a, X) ∈ def:var_def_in_comp, es decir, el individuo a participa en la relación con el individuo X.

Tipos de variables

A la hora de establecer comunicaciones, será necesario distinguir entre variables de las que se puede obtener un valor y aquellas en las que se puede escribir un valor. En EzWeb, se ha optado por dividir las variables en dos grupos: de lectura, y de lectura-escritura. En nuestro formalismo, estas se representan respectivamente con los conceptos def:ReadOnly_Variable y def:ReadWrite_Variable, que son subconceptos disjuntos de def:Variable.

Además de esta taxonomía, las variables se pueden clasificar atendiendo a su propósito. Para todos los componentes podemos distinguir entre:

• Variables de comunicación: eventos y slots (def:Event y def:Slot)
• Variables de contexto de plataforma, que permiten conocer el idioma del usuario y su identificador (def:PlatformContextVariable).
• Variables de estado, que permiten salvar y recuperar el estado de ejecución, proporcionando un mecanismo de persistencia (def:StateProperty).

Todos los conceptos descritos en la clasificación anterior se entienden disjuntos entre sí. Además, def:Slot y def:PlatformContextVariable serán subconceptos de def:ReadOnly_Variable, ya que sólo podremos usarlas para obtener valores (leer), y def:Event y def:StateProperty serán subconceptos de def:ReadWrite_Variable.

Todas las variables tendrán asociado un nombre, que deberá ser único para los componentes a los que pertenecen. Así, dos variables que pertenezcan a un mismo componente no podrán tener el mismo nombre. La representación formal de esta restricción será explicada más adelante en la sección "Unicidad de nombres". También tendrán una etiqueta, sobre la que se aplicará la misma restricción.

Modelo de mashups

Para poder crear composiciones (mash-ups) de componentes, debemos poder distinguir entre definiciones de componentes e instancias (ocurrencias) de componentes como parte de una composición. De esta forma, un conjunto de componentes ejecutándose en un workspace de un usuario correspondería en nuestro marco formal a un mashup, o conjunto de ocurrencias de componentes conectadas a canales de comunicación.

Representaremos las ocurrencias de componentes con el concepto occ:Component, y siempre deben estar asociadas a alguna definición de componente. La relación entre una ocurrencia y la definición a la que corresponde se representa mediante la propiedad def:occ_def_by (una relación funcional y total con dominio occ:Component y rango def:Component).

La figura a continuación muestra cómo representaremos las ocurrencias de componentes (en cian) y las definiciones de los mismos (en morado). Suponiendo que ambas ocurrencias (X1 y X2) siguen la definición X, este ejemplo muestra por qué hemos necesitado definir el nivel de ocurrencias (si no no podríamos distinguir X1 de X2).

Un mashup, que representaremos con el concepto occ:Mashup, estará compuesto de varias ocurrencias de componentes. Esta relación se representa en nuestra ontología como occ:composed_by, funcional y total, con dominio occ:Component y rango occ:Mashup.

Comunicación

La comunicación de componentes en EzWeb se lleva acabo mediante la creación explícita de canales. Los eventos conectados a un canal pueden enviar información al mismo, que recibirán todos los slots conectados a dicho canal. Al igual que con los componentes, debemos distinguir entre variables en el plano o nivel de definiciones de gadgets, y variables a nivel de ocurrencia de gadgets como parte de un mashup.

Para poder contemplar estas restricciones, añadimos los conceptos def:CommVariable, definida como la unión de def:Event y def:Slot, y occ:CommVariable. La relación entre occ:CommVariable y las definiciones (def:CommVariable) a las que corresponden se establece con la relación occ:var_occ_in_comp.

En este punto ya podemos introducir el concepto occ:Channel para representar canales de comunicación, y la propiedad occ:var_occ_linked_to, con dominio occ:CommVariable y rango occ:Channel para establecer qué variables están conectadas con qué canales.

Composición

El modelo descrito hasta ahora representar componentes y mashups de componentes. Nuestro objetivo es modelizar también la definición de componentes por combinación de otros más sencillos, permitiendo usar la plataforma de EzWeb como entorno de desarrollo.

La definición de componentes por composición establece una clara dicotomía: podemos caracterizar los componentes compuestos como aquellos construidos a partir de otros, y los simples como todos los demás. Para ello introducimos, respectivamente, los conceptos def:Compound y def:Simple, subconceptos disjuntos de def:Component. La diferencia entre ellos es que, además, def:Compound es también un subconcepto de occ:Mashup (que, recordemos, estaba definido como un conjunto de ocurrencias de componentes).

En los puntos anteriores vimos que las variables actúan como interfaz de los componentes con el "mundo exterior", es decir, con otros componentes. Los componentes compuestos también pueden tener variables de comunicación. Estas interfaces podrían definirse explícita o implícitamente. De forma inmediata, podemos proponer las siguientes soluciones:

• Las variables de todos los componentes internos pasan a ser, automáticamente, también del componente compuesto del que forman parte (componente externo).
• Las variables no conectadas a ningún canal de un componente interno pasan a ser, automáticamente, también del componente externo.
• Se debe dar explícitamente la lista de variables que formarán parte de la nueva interfaz.

La tercera opción, que hemos adoptado en nuestro modelo formal, aporta mayor flexibilidad al permitir publicar u ocultar variables según se desee.

Para poder establecer esta unión entre las variables publicadas por un componente compuesto y las variables de los gadgets que contiene, hemos decidido incluir la relación funcional occ:var_exposed_as, con dominio occ:CommVariable y rango def:CommVariable.

La siguiente imagen muestra un esquema de cómo definiríamos un nuevo componente, Y, como la composición de X1 y X2. En la figura vemos que el evento c de X1 envía datos al slot b de X2, y que las variables a (en X1) y c (en X2) son accesibles a través de las variables x y z del componente Y.

Tipos

La ontología descrita hasta ahora permite la conexión de gadgets tanto en mashups en un workspace como para definir nuevos componentes. Para garantizar que la comunicación es compatible (que los datos producidos por un gadget pueden ser consumidos por otro) es necesario establecer un sistema de tipos y dar una definición de compatibilidad. Esta definición nos permitirá, más adelante, hacer descubrimiento automático de componentes en base a los tipos de las variables de comunicación.

Este paso requiere, inicialmente, introducir un concepto para representar tipos, que denominaremos type:Type. La relación entre una variable y su tipo se define como def:has_type, que es funcional, total, tiene dominio def:CommVariable y rango type:Type. Esto indica que toda variable tiene exactamente un tipo.

A la hora de determinar si una variable puede "producir" datos que puedan ser consumidos por otra, introducimos un concepto más amplio que la mera igualdad de tipos. En vez de comprobar si los tipos de ambas son los mismos, deberemos comprobar si el tipo del productor (evento) es un subtipo (es compatible con, ó subsume en terminología de tipos) del consumidor (slot). Esto significa que todo dato producido tiene un tipo que también es del tipo consumido.

En la imagen anterior, si el tipo del evento c, t1, es un subtipo del tipo del slot b, t2, entonces todo valor de tipo t1 será también de tipo t2, con lo que la comunicación será compatible. Si esa condición no se cumple, no tenemos garantías de que los valores enviados a través de c puedan ser consumidos desde b.

Aunque podemos expresar esta relación, similar a la herencia en lenguajes de programación orientados a objetos, utilizando los subconceptos en ontologías, esto sólo sería aplicable si considerásemos a los tipos como conceptos y a sus individuos como los valores con esos tipos. En nuestro caso, los tipos son individuos de la ontología, no conceptos, por lo necesitamos una relación extra, que denominaremos type:is_subsumed_by, que representa el subtipado o compatibilidad, como sigue: decimos que un tipo A subsume a otro B (es decir, B type:is_subsumed_by A), si y sólo si, todas las instancias de B son también instancias de A.

En nuestra ontología modelizaremos esta restricción diciendo que la relación type:is_subsumed_by es transitiva y reflexiva.

Una vez tenemos esta relación, debemos añadir la restricción de que, para todo canal, los tipos de los eventos conectados a él son subtipos (subsumidos por) los tipos de los slots conectados al mismo. Esta restricción, no incluida aquí por el número de axiomas auxiliares que requiere, ha sido contemplada en la ontología final.

Unicidad de nombres

Al introducir las variables hemos establecido que existe unicidad de nombres, es decir, dos variables del mismo recurso (componente) no pueden tener el mismo nombre. La restricción de unicidad, enunciada como "una propiedad tiene un valor único para cada elemento", es sencilla de establecer en lógica descriptiva: basta con decir que la propiedad inversa es una relación funcional. Nuestro caso es ligeramente más complicado: queremos establecer que "todas las variables que pertenecen a un mismo componente tienen nombres distintos".

Podemos expresar nuestro problema de forma más general si decimos que una propiedad debe ser única para elementos en un mismo dominio. Supongamos que tenemos dos conceptos: E y D. E representa nuestros elementos, mientras que D representa los dominios. Existe una propiedad que relaciona un D con un E, denominada is_in ("E is_in D"), que además es funcional y total. Además, existe un conjunto de valores V (un concepto), y una propiedad que asigna a cada E un valor en V, que denominaremos has_value. Sabemos que has_value es funcional y total. Queremos establecer como restricción en nuestro modelo que no hay dos E en el mismo D que tengan el mismo valor para D.

Podemos construir una relación auxiliar denominada has_same_value_as, definida como has_value ◦ has_value ¯. Por su definición, sabemos que contiene parejas de elementos (E) que tienen el mismo valor (V) para la propiedad has_value. Esto no es un problema, ahora mostraremos cómo restringir el modelo para que no haya parejas de Es que estén en el mismo D.

Primero construimos una relación auxiliar similar de parejas de elementos que están en el mismo D:

is_in_same_as ≡ is_in ◦ is_in ¯

Ahora centramos nuestra atención en aquellas parejas que tienen el mismo nombre y están en el mismo compontente:

has_potential_clash_with ≡ is_in_same_as ⊓ has_same_value_as

El problema con la relación anterior es que determina que toda variable tiene una potencial colisión consigo misma (es un superconjunto de la relación identidad de E, que relaciona cada E consigo mismo).

Para simplificar esta relación, realizamos la siguiente definición, donde id(E) representa la relación identidad sobre el concepto E:

clashes_with ≡ has_potential_clash_with \ id(E)

Ahora podemos establecer el concepto al que pertenecerán todas las variables que tengan un clashing de nombres dentro de un mismo concepto como:

NameClashingVariables ≡ ∃clashes_with.

Siguiendo este esquema podemos obtener unicidad en un dominio (sustituyendo los nombres de forma apropiada). Sugerimos, sin embargo, el uso de la notación descrita en ^[1] cuando se use lógica descriptiva, y, a nivel de implementación, se puede usar el plugin de Protégé^[1] junto con el patrón de diseño Uniqueness-in-Domain (http://babel.ls.fi.upm.es/~iperez/ezweb/ontologies).

Simplificación automática de mashups y componentes complejos

Una de las aplicaciones que desearemos explotar de nuestra formalización es la optimización automática de componentes. Al no conocer nada sobre componentes específicos, las simplificaciones que podremos realizar a este nivel serán muy generales. Nos centraremos en la eliminación de canales inútiles.

Aunque no hemos dado una semántica operacional para nuestros componentes, de nuestra descriptición se deduce que los canales son meros transportadores de información, y sólo serán útiles si hay conectados a ellos tanto receptores como escritores.

El objetivo de esta sección no es decidir si un canal sin lectores, escritores, o ambos debe ser tratado como un error, sino cómo detectarlos formalmente para poder eliminarlos.

Comenzaremos definiendo los canales que actúan como sumideros de información (sólo tienen eventos conectados a ellos):

simp:ChannelWithEventsOnly ≡ occ:Channel ⊓ ∀(occ:var_def_by ◦ occ:var_occ_linked_to¯).def:Event

Esta definición garantiza que, si hay algo conectado a un canal, es necesariamente un evento (no que necesariamente lo haya).

De forma similar, los canales sin eventos sin puntos en los que nunca se producirá información, con lo que los slots conectados serán "inservibles". Podemos dar una definición de canales con sólo slots de forma análoga:

simp:ChannelWithSlotsOnly ≡ occ:Channel ⊓ ∀(occ:var_def_by ◦ occ:var_occ_linked_to¯).def:Slot

Además, podemos ser un poco más precisos dando definiciones de canales "aislados", es decir, que no realizan ninguna función en un mashup (están desconectados).

simp:UnconnectedChannel ≡ simp:ChannelWithSlotsOnly ⊓ simp:ChannelWithEventsOnly

La figura a continuación muestra una composición con dos canales. El de la derecha, conectado sólo a la variable C de X2, puede ser eliminado, ya que al tener sólo escritores nunca se llegará a leer de él.

Semántica "blanda" de componentes

Los componentes descritos hasta ahora tienen todos los elementos necesarios para poder describir y analizar composiciones. A nivel de plataforma, sin embargo, falta incluir aquellas características que permiten identificar e instanciar un componente. La mayor parte de la información que falta por declarar puede extraerse de la plantilla XML que define un gadget en EzWeb. De ella concluimos que debemos incluir los siguientes campos para todos los componentes:

• Nombre
• Version
• Vendor
• Autor
• Email
• Descripción
• URL donde puede ser localizada una imagen del componente.
• Página web (Posiblemente, en un wiki)
• URL del fichero XHTML que implementa el componente.

La tabla siguiente resume los nuevos conceptos y relaciones incluidos para cada elemento de la lista anterior.

Elemento	Relación	Rango de la relación
Nombre	has_comp_name	ComponentName
Version	has_comp_version	ComponentVersion
Vendor	has_comp_vendor	ComponentVendor
Autor	has_comp_author	ComponentAuthor
Mail	has_comp_mail	EMailAddress
Description	has_comp_description	ComponentDescription
ImageURL	has_comp_image	URL
WebPageURL	has_comp_webpage	URL
XHTML URL	has_comp_code	URL

Todas las relaciones de la lista anterior son funcionales y totales.

En el sistema no puede haber dos componentes con el mismo nombre, vendor y versión. Podemos incluir esta restricción creando una clase auxiliar que represente una tupla (Name, Vendor, Version), y diciendo que existe una relación 1 a 1 entre ese concepto y el de definiciones de gadgets (que además deberá mantener la igualdad de nombre, vendor y versión).

D 2.2.2 Análisis, especificación y listado de ontologías para describir contenidos

El presente documento profundiza en las características más relevantes de los contenidos, realizando un análisis de los mismos y ofreciendo una ontología que los formaliza completando de esta forma la información del documento #D.2.2.1 Requisitos, análisis y listado de ontologías para describir los recursos generales de EzWeb.

Análisis de contenidos

Además del análisis común para todos los recursos se pueden reseñar un par de detalles propios de los contenidos:

• La fuente de datos de un contenido se describe con una URI externa. Propiedades: has_external_source.

• Los contenidos se gestionan bajo arquitectura REST. En otras palabras, sobre un contenido se pueden ejecutar las operaciones GET, PUT, POST y DELETE que se delegan en la fuente de datos. Por tanto, un contenido tiene 4 slots que recibirán los datos de cada una de las posibles acciones, y 4 eventos (uno para cada posible resultado). Dado que es una operación asíncrona, no se presupone una correlación temporal entre las entradas y salidas de un contenido.

La versión actual de la ontología no plantea la posibilidad de capturar un fallo en la conexión con la fuente externa de un recurso. Si se desea capturar un error, podria tenerse una salida especializada para errores, o encapsular las salidas de las operaciones REST en un tipo que indique el resultado (acerito, o fallo) de la operación además del contenido en sí mismo. Esta opción deberá ser explorada si se decide extiender este formalismo con tipos polimórficos.

La conversión entre cadenas de caracteres y tipos básicos (como tipos de XML Schema) está predefinida y puede realizarse automáticamente al asignar tipos a las entradas y salidas de un contenido. En caso de tratarse de tipos de datos más complejos para los que no se puede derivar una operación de parsing automáticamente, el contenido puede ser encapsulado en un servicio de back-end que realiza la comprobación y conversión de tipos.

Formalización de contenidos

La formalización de los contenidos es parte de la ontología http://babel.ls.fi.upm.es/~iperez/ezweb/ontologies.

Para representar los contenidos se ha definido un concepto def:Contenido, que tiene una propiedad que lo asocia con cada variable de entrada y salida (4 entradas y 4 salidas, una para cada posible acción REST).

Sugerimos al lector experimentado que instale la herramienta Protégé (u otra herramienta que sea compatible con OWL) y visualice la formalización a través de la misma. En la ontología hay anotaciones sobre conceptos y propiedades que completan la sección anterior.

Al lector menos experimentado creemos que puede serle de gran utilidad visitar la página generada desde la herramienta y que contiene los conceptos y propiedades con la posibilidad de realizar navegación a través de la misma: http://babel.ls.fi.upm.es/~iperez/ezweb/ontologies.

Optimizaciones de mashups con contenidos

Al igual que hicimos con los canales, podemos optimizar nuestros mashups si eliminamos aquellos contenidos que no pueden ser utilizados. En concreto, podemos simplificar las siguientes situaciones:

• Un contenido que tiene conectada la salida de una acción pero no la entrada.
• Un contenido que no tiene conectada ninguna entrada.

Para el primero caso podremos simplificar nuestros mashups eliminando la conexión entre la salida conflictiva y el canal al que está enlazada. En el segundo, podemos eliminar el contenido.

D 2.2.3 Análisis, especificación y listado de ontologías para describir servicios

Además de las carácteristicas comunes a todos los recursos que están recogidas en el apartado previo de formalización, el presente documento profundiza en las características más relevantes de los servicios, realizando un análisis de las mismos y ofreciendo una ontología que los formaliza completando de esta forma la información del documento #D.2.2.1 Requisitos, análisis y listado de ontologías para describir los recursos generales de EzWeb.

La composición de servicios y de recursos en general debe ser tratada con especial cuidado, por su solapamiento con el objetivo de otros puntos del proyecto y de otros proyectos. La formalización de la composición está sujeta a la posibilidad de hacer preguntas que aprovechen tal información, y debe ser revisada a medida que avance el proyecto. OWL-S y WSMO son iniciativas para la construcción de Servicios Web Semánticos. La introducción de algo similar en EzWeb aumentaría notablemente la complejidad en la resolución de dichas consultas, haciendo impracticable su utilización para el descubrimiento de recursos y haciendo necesario otro enfoque.

Análisis de servicios

• Se distinguen dos tipos de servicios: los servicios web tal y como se entienden en el contexto de la web semántica, es decir, servicios disponibles en algún sitio de internet, accesibles a traves de un API públicamente accesible, y servicios legacy u operadores. En nuestro contexto, hemos explorado los segundos, ya que estándares como OWL-S y WSMO ya se encargan de analizar el primer tipo de servicios.

• Al igual que ocurría con los componentes generales, los servicios se dividen en dos tipos: servicios básicos o preprogramados (en general programados a mano con scripting y descritos con una simple URI) y servicios creados por composición de otros recursos.

Características deseables pero no analizadas

• La ejecución de servicios es concurrente. Cualquier análisis de la semántica de recursos debe tener en cuenta que, aun cuando la implementación se base en un único hilo de ejecución, no se puede presuponer un órden específico de ejecución de recursos a menos que se imponga usando mecanismos explícitos de sincronización o cuando se imponga por la orquestración diseñada.

• Los servicios tienen estado interno en forma de variables. Clases: Variable. Propiedades: has_var_state, var_state_defined_in (Este aspecto deberá ser estudiado en más detalle con el análisis de modelos de comunicación: no consistuye una buena política de diseño que los servicios y gadgets abran su estado interno o que expongan los datos intercambiados con otros recursos a terceros. Con ello se mezclan mecanismos de comunicación diferentes).

• Un servicio puede dejar de escuchar en un canal dependiendo de una guarda que depende del estado interno.

• Los canales de comunicación pueden tener diferentes comportamientos dependiendo de si almacenan mensajes (paso de mensajes asíncrono) o no (paso de mensajes síncrono, el servicio que envía los datos queda bloqueado hasta su recepción), si se replican los mensajes para cada servicio receptor (comportamiento como el de la arquitectura Qt), si se pierden los mensajes ante la llegada de nuevos mensajes, etc.

Formalización de servicios

Esta sección describe con detalle la formalización de servicios en la ontología (la cual puede ser descargada desde http://babel.ls.fi.upm.es/~iperez/ezweb/ontologies).

Sugerimos al lector experimentado que instale la herramienta Protégé (o bien otra herramienta compatible con OWL) y visualice la formalización a través de la misma. En la ontología hay anotaciones sobre conceptos y propiedades que completan la sección anterior.

Al lector menos experimentado creemos que puede serle de gran utilidad visitar la página generada desde la herramienta y que contiene los conceptos y propiedades con la posibilidad de realizar navegación a través de la misma, también disponible en: http://babel.ls.fi.upm.es/~iperez/ezweb/ontologies.

Operadores

Uno de nuestros objetivos es extender EzWeb con componentes que no sean sólo gadgets o aplicaciones gráficas. Podemos tomar la decisión de crear un gadget que no crea una interfaz gráfica (simplemente ejecuta un código Javascript), pero podemos ir un paso más allá si extendemos nuestro formalismo para considerar de forma específica todos aquellos componentes que funcionan como servicios legacy. Para evitar la colisión de nombres con otros servicios (por ejemplo, servicios web) o con futuras extensiones de esta definición, contemplaremos los transformadores de datos de forma específica. Dado que no queremos ser demasiado estrictos en este punto, simplemente extenderemos nuestros componentes con nuevos subconceptos más específicos de los que conocemos algunas de su semántica.

Comenzaremos definiendo los operadores como componentes sin interfaz gráfica, estado o acceso al contexto, con una entrada y una salida. Deben estar implementados de forma que sólo produzcan valores si se recibe un valor en alguna entrada. Los operadores representan componentes sin vista que realizan operaciones matemáticas sencillas, transformaciones entre unidades, etc.

Una de las propiedades que nos interesará analizar es bajo qué condiciones la composición de operadores es también un operador. Conociendo las propiedades dadas en esta sección, también podremos optimizar nuestros mashups o composiciones eliminando los operadores no conectados a un canal, y podremos detectar situaciones anómalas (como ciclos de comunicación que podrían provocar bucles infinitos o fuentes de datos interminales).

Primero, estableceremos una división de componentes en componentes sin vista y componentes gráficos, o gadgets, diciendo que def:Component es la unión de las clases disjuntas ext:ViewLess_Component y ext:Gadget. Los operadores, que representaremos con el concepto ext:Operator serían un subconcepto de los componentes sin vista (ext:ViewLess_Component).

Antes de continuar, podemos ver que en nuestro modelo se cumplen las siguientes propiedades:

• Si un componente compuesto es ext:Gadget si y sólo si alguno de sus componentes internos también lo es.
• Si un componente compuesto es ext:ViewLess_Component si y sólo si todos sus componentes internos también lo son.

A continuación veremos un tipo específico de adaptadores que nos interesan especialmente por las posibilidades de descubrimiento automático que nos brindan. Más adelante podremos comprobar bajo qué condiciones una composición de operadores es también un operador y qué operadores podemos eliminar de un mashup sin afectar al resultado obtenido.

Adaptadores

Una vez que hemos establecido esta división, podemos profundizar un poco más en componentes sin vista, intentando explotar nuestro modelo. Uno de los puntos analizados anteriormente son los tipos. Cuando el usuario de la plataforma especifica una situación de incompatibilidad de tipos, un simple mensaje informativo puede no ser suficiente. Además de que hay usuarios que pueden no entender qué significa, la solución requiere visitar el catálogo y buscar un gadget que tenga tipos correctos y que podamos poner en el lugar de alguno de los componentes presentes en nuestro mashup.

Para facilitar la corrección de estas situaciones, se puede optar por introducir un nuevo tipo de componente: el adaptador. Un adaptador sería, según nuestra definición, un operador que toma datos de un tipo y los devuelve con otro tipo. Un adaptador de, por ejemplo, Enteros a Strings sería un componente que toma datos de tipo Entero y devuelve elementos de tipo String, y podríamos utilizarlo para garantizar la compatibilidad en una comunización entre un componente que produce Enteros y un componente que consume Strings. Las dos siguientes figuras de esta sección muestran, respectivamente, una situación de incompatibilidad de tipos y cómo se resolvería con un adaptador (Adapter1) de enteros a strings.

De forma más cercana a nuestro modelo podemos definir un adaptador como un componente sin vista que tiene exactamente una entrada (slot) y una salida (evento). Nótese que no todo elemento que cumpla estas características es un slot. Decimos que un componente es un adaptador del tipo A al tipo B si es un adaptador y tiene un slot de tipo A y un evento con tipo B. Podemos caracterizar formalmente estas definiciones añadiendo los siguientes axiomas:

ComponentWithOnlyOneSlot ≡ def:Component ⊓ =1.def:var_def_in_comp¯.def:Slot

ComponentWithOnlyOneEvent ≡ def:Component ⊓ =1.def:var_def_in_comp¯.def:Slot

ext:Adapter ⊑ ext:Operator ⊓ ComponentWithOnlyOneSlot ⊓ ComponentWithOnlyOneEvent

Dados dos tipos (TypeA ⊑ type:Type y, definido análogamente, TypeB), podemos incluir las siguientes restricciones para garantizar que un adaptador va de un tipo a otro. Primero definimos un concepto para los slots de tipo TypeA y para los eventos de tipo TypeB:

SlotTypeA ≡ def:Slot ⊓ ∀ def:has_type.TypeA

EventTypeB ≡ def:Event ⊓ ∀ def:has_type.TypeB

Ahora utilizamos los axiomas que definen a un adaptador para restringir el slot y el evento a los conceptos definidos en los dos axioms anteriores:

ComponentWithSlotTypeA ≡ def:Component ⊓ =1 . def:var_def_in_comp¯ . def:SlotTypeA

ComponentWithEventTypeB ≡ def:Component ⊓ =1 . def:var_def_in_comp¯ . def:EventTypeB

ext:AdapterFromAToB ⊑ ext:Operator ⊓ ComponentWithSlotTypeA ⊓ ComponentWithEventTypeB

Descubrimiento automático de adaptadores

Una vez que tenemos adaptadores, podemos solucionar una incompatibilidad de tipos en un mashup sugiriendo al usuario que utilice un adaptador en medio de una comunicación.

Podemos solucionar una incompatibilidad entre un evento con tipo A y un slot con tipo B, conectados al mismo canal, si definimos la clase de los adaptadores de A a B. Sólo tenemos que comprobar qué individuos pertenecen a dicho concepto para saber si podemos utilizarlos para solucionar una incompatibilidad en la comunicación.

Podemos ir un paso más allá si, en vez de limitarnos a aquellos componentes que tengan exactamente los tipos requeridos, buscamos componentes en los que el slot sea de un tipo supertipo del que intentamos conectar y el evento sea de un subtipo del del slot de la comunicación incorrecta.

A nivel formal, podemos obtener el concepto buscado si, en los axiomas del apartado anterior, sustituimos los conceptos TypeA y TypeB por TypeSubsumesA y TypeSubsumedByB, definidos como sigue:

TypeSubsumesA ≡ type:Type ⊓ ∃ type:is_subsumed_by ¯ . TypeA

TypeSubsumedByB ≡ type:Type ⊓ ∃ type:is_subsumed_by . TypeB

El resultado del resto de los axiomas tras la sustitución sería el siguiente:

SlotTypeSubsumesA ≡ def:Slot ⊓ ∀ def:has_type . TypeSubsumesA

EventTypeSubsumedByB ≡ def:Event ⊓ ∀ def:has_type . TypeSubsumedByB

ComponentWithSlotTypeSubsumesA ≡ def:Component ⊓ =1 . def:var_def_in_comp¯ . def:SlotTypeSubsumesA

ComponentWithEventTypeSubsumedByB ≡ def:Component ⊓ =1 . def:var_def_in_comp¯ . def:EventTypeSubsumedByB

ext:AdapterCompatibleFromAToB ⊑ ext:Operator ⊓ ComponentWithSlotTypeSubsumesA ⊓ ComponentWithEventTypeSubsumedByB

Podemos realizar sugerencias más potentes o, simplemente, contemplar más casos, si no limitamos nuestras búsquedas a adaptadores que existan en el catálogo, sino que dinámicamente generamos adaptadores para el usuario. La generación automática de componentes es un proceso complejo y está limitado, principalmente, por nuestras limitaciones para especificar la semántica de los gadgets. Por ello, limitaremos nuestra búsqueda a las cadenas de adaptadores, de forma que se pueda tener una alta confianza en que la cadena generada produzca el resultado deseado. La figura a continuación muestra cómo podríamos encadenar adaptadores para resolver una incompatibilidad entre un evento que produce número reales y un slot que espera cadenas de caracteres.

Definimos un nuevo concepto, ext:AdapterChain, que representa las cadenas de adaptadores. Una cadena de adaptadores es un componente compuesto sólo de adaptadores, en los que todas las variables están conectadas a algún canal, no contiene ciclos, y existe un camino desde la única entrada, pasando por todos los adaptadores, hasta la única salida. La figura a continuación muestra un posible componente que la plataforma podría generar automáticamente.

Los axiomas, bastante más complejos que los de los adaptadores simples, se pueden consultar en Gadget Composition and automatic discovery in EzWeb ^[1], página 32, y http://babel.ls.fi.upm.es/~iperez/ezweb/ontologies.

Podemos obtener una cadena que resuelve un problema de comunicación entre un slot de tipo B y un evento de tipo A buscando las cadenas de adaptadores que son, a su vez, un adaptador de un tipo que subsume A a un tipo subsumido por B.

Detección de operadores no usados

De forma similar a lo ocurrido con los canales, un operador sólo es útil si está conectado a otros recursos que no son operadores. Además, si sólo es fuente de datos o consumidor (tiene sus eventos o sus slots desconectados), podemos eliminarlo sin afectar a nuestra composición.

Nótese que, en este contexto, siempre hablamos de instancias de componentes y no de definiciones, a menos que se indique explícitamente lo contrario.

Esto nos permite definir los siguientes conceptos, cuyas formalizaciones pueden ser consultadas en la ontología http://babel.ls.fi.upm.es/~iperez/ezweb/ontologies y en Gadget Composition and automatic discovery in EzWeb ^[1]:

• simp:DisconnectedOperator: representa operadores que tienen variables no conectadas.
• simp:OperatorThatReachesOnlyOperators: representa operadores cuyos resultados sólo afectan a operadores.
• simp:OperatorThatReachesNoPublishedVar: representa operadores que son parte de un componente sin vista y cuyos efectos nunca son pueden ser patentes en otro componente que no sea un operador.

Cualquiera de los operadores descritos pueden ser eliminados (haciendo las modificaciones oportunas para mantener la consistencia de nuestra base de conocimiento), simplificando nuestros mashups o recursos compuestos sin afectar al resultado de los mismos.

D 2.2.4 Análisis, especificación y listado de ontologías para describir gadgets

El presente documento profundiza en las características más relevantes de los gadgets, realizando un análisis de los mismos y ofreciendo una ontología que los formaliza completando de esta forma la información del documento #D.2.2.1 Requisitos, análisis y listado de ontologías para describir los recursos generales de EzWeb.

Análisis de gadgets

Los gadgets son componentes con interfaz gráfica. A nivel formal pueden verse como servicios con "vista": todas las propiedades aplicables a servicios que no vengan derivadas de ser componentes sin vista son aplicables a Gadgets. Por tener representación gráfica, los gadgets tienen además las siguientes características:

• Sus templates deben indicar un tamaño por defecto en pantalla.
• Tienen acceso a las variables de contexto de gadget
• Pueden tener preferencias, es decir, variables configurables en tiempo de ejecución cuyo valor es establecido por el usuario.

Algunas de las declaraciones de los templates de los componentes no son comprobadas en tiempo de ejecución (por ejemplo, que un valor es de un tipo), y es necesario "fiarse" del desarrollador. Para los gadgets, existe la opción de incluir un modelo formal para la interfaz gráfica de usuario, permitiéndonos dar una vista y un controlador por separado. Sin embargo, para ser útil, este modelo debería contemplar formalmente todas las construcciones típicas dadas en HTML, Javascript, CSS, Adobe Flash, etc., con lo que su análisis podría volverse impracticable. en lugar de eso, intentaremos proveer una lista de gadgets lo suficientemente extensa, de bajo nivel, y con una semántica precisa para poder realizar análisis potentes sobre las definiciones de gadgets.

Formalización de gadgets

La formalización de los gadgets es parte de la ontología http://babel.ls.fi.upm.es/~iperez/ezweb/ontologies.

Sugerimos al lector experimentado que instale la herramienta Protégé (o bien otra herramienta compatible con OWL) y visualice la formalización a través de la misma. En la ontología hay anotaciones sobre conceptos y propiedades que completan los documentos anteriores.

Preferencias

En la sección Tipos de variables del entregable D 2.2.1 dábamos una lista de variables de los componentes. Para los gadgets, incluimos unas nuevas variables llamadas preferencias: campos cuyos valores pueden ser establecidos por el usuario en tiempo de ejecucion o por el desarrollador de mashups en tiempo de diseño (composición). La figura siguiente muestra cómo se presentan al usuario las preferencias de los gadgets.

A nivel formal, podemos contemplar estos cambios incluyendo las propiedades funcionales totales def:has_pref_name, def:has_pref_type, def:has_pref_label y def:has_pref_description que tienen como dominio def:Preference y como rangos, respectivamente, los conceptos def:PrefName, def:PrefType, def:PrefLabel y def:PrefDescription.

Si el tipo de preferencia es list, se darán para la variable una lista de opciones entre las que el usuario puede seleccionar una. Podemos considerar esta restricción con los siguientes axiomas:

def:PrefType ≡ {text, number, boolean, password, list}

def:PrefTypeList ≡ {list}

def:PrefTypeNonList ≡ def:PrefType ⊓ (¬ def:PrefTypeList)

def:Preference ≡ def:NonListPreference ⊔ def:ListPreference

def:ListPreference ≡ def:Preference ⊓ (∀ def:has_pref_type.def:PrefTypeList)

def:NonListPreference ≡ def:Preference ⊓ (∀ def:has_pref_type.def:PrefTypeNonList)

Esto nos permite declara unas preferencias para un gadget, pero no nos permite:

• Dar valores por defecto para dichas preferencias.
• Contemplar los cambios de valor en esas variables que se pueden hacer al construir un gadget compuesto.

Para incluir las características anteriores, ampliamos nuestro modelo con las propiedades def:pref_has_default_value y occ:pref_occ_has_value, ambas funcionales y totales, que tienen como dominios def:Preference y occ:Preference respectivamente, y como rango def:PrefValue.

Tamaño de los gadgets

El tamaño de los gadgets debe ser contemplado en dos niveles: en el template, para establecer su tamaño de renderizado inicial (y mínimo), y en una composición, para establecer su tamaño de renderizado como parte de ella (que puede ser modificado por el usuario).

A nivel formal, el cambio que debemos realizar en el template consiste en añadir la relación pos:def_has_size de forma análoga a las propiedades añadidas en secciones anteriores, con los siguientes axiomas:

⊑ ∀ pos:def_has_size ¯. def:Gadget

⊑ ∀ pos:def_has_size . pos:Size

def:Gadget ⊑ =1 pos:def_has_size .

Según los axiomas anteriores, el dominio de la función total es def:Gadget y el rango pos:Size.

Esto nos permite dar un "tamaño por defecto", pero cuando un gadget es instanciado (en diseño o en ejecución), el usuario puede modificar su tamaño, situación que además podrá ser notificada al gadget. Para notificar al gadget, podemos usar variables de contexto, creando un nuevo tipo de variables de sólo lectura: las variables de contexto de gadget. Estas deberán estar asociadas a dos nombres de elementos de contexto de los gadgets: su ancho (width) y su alto (height) en tiempo de ejecución.

Los axiomas para esta nueva relación serían los siguientes:

⊑ ∀ pos:occ_has_size ¯ . occ:Gadget

⊑ ∀ pos:occ_has_size . pos:Size

occ:Gadget ⊑ =1 pos:occ_has_size.

Análogamente a la anterior, es una relación funcional y total, con rango pos:Size y dominio occ:Gadget

Gadgets con semántica conocida

En secciones anteriores hemos visto cómo tener servicios con semántica (parcialmente) conocida nos permite realizar un análisis más profundo de las composiciones y dar optimizaciones o detecciones de errores ms avanzadas. En esta sección haremos lo mismo, proporcionando una lista de gadgets cuya semántica conocemos y sobre las cuáles podremos realizar optimizaciones posteriores.

Podemos inspirarnos en la creación de esta lista de gadgets tomando las listas de controles (u objetos visuales) comunes en entornos de programación visual o librerías como GTK.

En http://babel.ls.fi.upm.es/~iperez/ezweb damos una lista de gadgets que contiene las siguientes definiciones:

• Gadget label (etiqueta): sólo muestra un texto que es configurable con una variable de preferencia.
• Gadget button (botón): muestra un botón cuyo texto es configurable con una variable de preferencia y envía "0" en su salida cuando el botón es pulsado.
• Gadget list (lista): muestra una lista, cuyo contenido se obtiene por una entrada, y envío el elemento seleccionado (cuando se pulsa una fila) en su salida.
• Gadget textbox (caja de texto): muestra una caja de texto, cuyo estado se salva cuando es modificada. El contenido se envía por su único evento al pulsar la tecla intro, y cuando se recibe algo en su único slot, se muestra en la caja.
• Gadget checkbox: muestra una opción activable y desactivable. El estado inicial y el texto son configurables con preferencias. Envío un valor "true" o "false" en su salida cuando cambia su estado, y cambia su estado si se recibe un valor "true" o "false" por su entrada.
• Gadget imagen: carga una imagen (URL seleccionable por una preferencia).
• Gadget flash: carga un objeto de tipo flash (URL seleccionable por una preferencia).
• Gadget generador de datos: envía por su salida un dato cuando se inicia. Nos permite inicializar la entrada de otro gadget o servicio con un valor por defecto, particularizándolo para un propósito más específico. Por ejemplo, nos permitiría inicializar un gadget list con una lista concreta de valores. Su salida es siempre un String, que deberá ser convertida al tipo necesario para la entrada del componente al que se quiera conectar, para lo que podría utilizarse un adaptador (como se vio en el documento D 2.2.3).

Optimizaciones y detección de errores

Entre estos gadgets, estaremos especialmente interesados tipos: aquellos que tienen entradas obligatorias, y aquellos que tienen salidas "obligatorias". Un botón, por ejemplo, podría constuirse como un gadget que envía un evento cuando es pulsado. Si nada está conectado al evento (no hay un canal y un slot en él), entonces no tendrá efectos (será un botón inútil en medio de la pantalla) y es probable que lo queramos eliminar.

Es importante hacer incapié en que, al tratarse de elementos que tienen una apariencia visual, no podemos eliminarlos manteniendo la semántica de la composición en ningún caso: la mera presencia del gadget en pantalla podría tener significado para el diseñado. Todas las "optimizaciones" dadas en este apartado deberán interpretarse como meras sugerencias o, en el caso de detección de errores, como "warnings".

Podemos dividir los gadgets del apartado anterior en los siguientes grupos:

• Slot obligatoriamente conectado: list, generador de datos
• Evento obligatoriamente conectado: button, checkbox, list

Esto nos permite usar el mismo razonamiento aplicado a canales y operadores en documentos anteriores y proveer sugerencias cuando:

• Una ocurrencia de gadget list o generador de datos no tiene su slot conectado a ningún canal.

• Una ocurrencia de gadget button, checkbox o list no tiene su event conectado a un canal.

Referencias

Apéndice: Ontología de recursos EzWeb en OWL

El estado actual de la ontología que especifica los recursos EzWeb está disponible en

http://babel.ls.fi.upm.es/~iperez/ezweb/ontologies