D 2.2 Descripción semántica de recursos

De MorfeoWiki

(Redirigido desde D.2.2 Descripción semántica de recursos)

PROFIT

Morfeo-EzWeb

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

Entregable:

D 2.2 Descripción semántica de recursos

Versión:	0.1
Fecha de preparación:	4 de abril de 2008
Editores:	IMDEA - Ángel Herranz (AH) - aherranz @ fi upm es - +34913366903
Revisores:	??? (INTERCOM), Sergio Fernández (Fundación CTIC), Raúl Peña (ITI)

Tabla de contenidos

1 Resumen y objetivos
2 D 2.2.1 Requisitos, análisis y listado de ontologías para describir los recursos generales de EzWeb
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
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
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
6 Referencias
7 Apéndice: Ontología de recursos EzWeb en OWL

[editar]

Resumen y objetivos

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

Definir un marco formal para la descripción de recursos dentro del proyecto EzWeb.
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 3.3.1) 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.

Hacer en siguientes versiones: Ni la arquitectura actual (cerrando 2007) ni la memoria del proyecto contemplan cómo EzWeb puede explotar la semántica de los recursos y del contexto que se ofrece en este documento. Un elemento fundamental en la elección del formalismo es conocer qué preguntas se van a hacer al sistema puesto que no habrá necesidad de capturar aquello sobre lo que no se pregunte. — A. Herranz

[editar]

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

Ésta 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.

[editar]

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 en la memoria del proyecto:

Cuando un recurso ofrece acceso a fuentes de datos permitiendo su consulta o modificación nos encontramos ante un tipo de recurso denominado contenido^[2].
Cuando un recurso realiza un procesamiento de información obtenida de otros recursos nos encontramos ante un tipo de recurso denominado servicio^[2]. Además, 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^[2].
En la memoria del proyecto se fuerza, de alguna forma^[3], una linea en la semántica de los recursos al ser definidos como componentes software dentro del paradigma REST (Representational State Transfer ^[4]^[5]): 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, posiblemente 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.

Hacer en siguientes versiones: Respecto al paradigma REST, aparece en la memoria del proyecto aunque tal y como está definida la plataforma actualmente (cerrando 2007) parece NO ser estrictamente necesario o no estar siendo usado. En todo caso, la ontología intenta capturar en su semántica el posible uso de REST y en futuras versiones del documento deberá contrastarse si la semántica refleja realidades de la plataforma. — L. Polo, A. Herranz

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 se considera que se deben capturar, como el vendor, autor, fecha de creación, gráfico de presentación, etc. Sin embargo, está claro que aunque los usuarios puedan 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).

[editar]

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.

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.

[editar]

Soluciones en la web semántica

En esta sección se realiza un resumen conciso 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^[6]: "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^[7]) 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^[8] 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^[9] como OIL (Ontology Inference Layer^[10]), DAML+OIL (DARPA Agent Markup Language + OIL^[11]), RDFS (RDF Schema^[12]) y OWL (Ontology Web Language^[13]).

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. Éste es el análisis que nos lleva a tal conclusión:

OWL y RDFS son los lenguajes más extendidos para describir ontologías en la web.
OIL y DAML+OIL quedarían descartados, son lenguajes desfasados cuya evolución ha dado como fruto OWL.
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.
Sobre RFDS hay dudas^[14] sobre lo adecuado que es más allá de lenguaje de metadatos.
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).
OWL tiene asociados lenguajes de razonamiento y de interrogación suficientemente contrastados como pueden ser KAON2^[15] y OWL-QL^[16].

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

[editar]

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^[17], FOAF^[18], SKOS^[19], Dublin core^[20].

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.

[editar]

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.

De forma muy concisa pasamos a mencionar algunos criterios de busqueda de ontologías que deberán ser analizadas:

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.

[editar]

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.

Hacer en siguientes versiones: Además de requisitos educibles de los resultados de los documentos citados, existen 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. — Iván Pérez y Ángel Herranz

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. Esto podría ser capturado en el modelo de forma específica. En caso afirmativo 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^[21] o OWL-S^[22].
- Lenguajes para especificación de servicios web basados en arquitectura RESTful como WRDL^[23], Resedel^[24], WADL^[25], SMEX-D^[26]
- Otros lenguajes, quizá más complejos, para especifcar servicios web: WSDL v2.0^[27], WSML^[28], RDF-Forms^[29].

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^[30] o el formato usado en Qt^[31]). 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.

Podría permitirse que un recurso sea configurable en tiempo de diseño, es decir, que existan parámetros del recurso que el usuario de la plataforma pueda establecer pero que tengan unos valores dados por defecto.

[editar]

Formalización 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 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 utilizando la herramienta Protégé para su desarrollo (pero pudiendo utilizarse cualquier otra para su consulta o modificación). Consideramos esta formalización como un prototipo que permitirá profundizar en el entendimiento y comprensión de lo que se espera de la plataforma a la par que debe permitir la discusión de sus características por parte de todos los participantes.

La formalización en OWL puede ser descargada desde http://babel.ls.fi.upm.es/~angel/ezweb/semantics/ezweb-simple-resources.owl.

Sin entrar en los detalles de formalización de cada tipo de recurso, la ontología debería capturar el siguiente conocimiento general (parte de él no será recogido en la primer versión de la semántica pero se incluye para que se tenga en cuenta en futuras versiones):

NOTA - AH: he decidido anotar cada punto del análisis con referencia a los conceptos, propiedades y restricciones relevantes que los capturan dentro de la ontología. Creo que es una decisión correcta para pasar el testigo a un nuevo editor pero con respecto a la versión final... es una fuente de redundancia imposible de gestionar. CUIDADO con ello.

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 o descripción de recursos y ocurrencia de recursos. En esta primera versión de la semántica no se contempla la composición de recursos. Por tanto no es necesario tratar con las ocurrencias de recursos. Solo existirá una clase que representará los recursos (la definición de un recurso). Clases: Resource. En futuras versiones será necesario introducir el concepto de las ocurrencias cuando se introduzca en la semántica la composición. Clases: Resource_def, Resource_occ.

Cada definición de recurso tiene asociado un URI interno a la plataforma.

En esta primera versión de la semántica no se representa la comunicación entre recursos (implícita cuando se tenga en cuenta la composición). En futuras versiones, habrá que considerar que las ocurrencias de recursos envían mensajes (también denominados eventos o señales) a través de puntos de salida que se han denominado signals en la ontología y que se definen mediante un nombre y una descripción de los datos que pueden encapsularse en el mensaje (en una misma definición de recurso no se repiten nombres). Clases: Signal_def, Type. Propiedades: output_def.

Del mismo modo deberán tenerse en cuenta en futuras versiones que las ocurrencias de recursos reciben mensajes a través de puntos de entrada denominados slots en la ontología y que se definen mediante un nombre un esquema de datos (en una misma definición de recurso no se repiten nombres, aunque puede resultar mas sencillo utilizar directamente las URIs). Clases: Slot_def, Type. Propiedades: input_def.

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 recursos para los usuarios como a ayudar a sugerir a usuarios menos experimentados puntos de conexión entre gadgets). Una decisión que podría tomarse es hacer pertenecer cualquier definición de datos a un concepto data 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. De momento se ha definido una clase y dos propiedades para representar esta información Clases: Type. Propiedades: type_of_component, type_of_resource.

Se ha decido representar la información estática referente a las características de un recurso mediante una colección de propiedades todas ellas definidas como basic_resource_data sobre un recurso (dominio). El tipo de su rango depende de cada una y puede que sea una buena opción importar clases ya definidas en otras ontologías bien conocidas. De momento no se han especificado. Propiedades: persisten-state, rendering, context_data version, creation_date, preference, description, imageURI, author_email, data_wiring, other, author_name, wikiURI.

Se acompaña la siguiente imagen de la jerarquía completa de conceptos de la ontología:

La imagen que muestra las propiedades que relacionan las clases principales se adjunta a continuación:

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

[editar]

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

El presente documento profundiza en las características 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.

[editar]

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. Se han creado cuatro propiedades (type_of_resource) que relacionan un contenido con su tipo en cada una de estas operaciones.Propiedades: post_type_of_content, delete__type_of_content, get_type_of_content, put_type_of_content.

NOTA - IP: siempre es posible que los tipos de entrada y salida sean siempre String, de esa forma los contenidos deberían encapsularse en servicios de backend que realiza comprobación y conversión de tipos. A favor: el modelo de contenidos es trivial: la uri externa. En contra: siempre es necesaria la encapsulación si los tipos no son el texto plano tal cual llega de la fuente de datos.

NOTA - IP: en caso de fracaso en la consulta a la fuente de datos... ¿qué se produce como salida? Si se indica el código de error en la salida es posible que el tipo de la salida real de los contenidos sea REST RESPONSE que capture posibles errores y el tipo asociado en caso de que no haya errores.

Se acompaña la siguiente imagen de las propiedades relacionadas con un contenido:

[editar]

Formalización de contenidos

La formalización de los contenidos es parte de la ontología http://babel.ls.fi.upm.es/~angel/ezweb/semantics/ezweb-simple-resources.owl.

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/~angel/ezweb/semantics/ezweb-simple-resources.owl.

[editar]

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.

Revisión: En este punto, creo que Marcos tiene razón en que la composición y mediación de datos entre servicios utilizando semántica debería caer fuera de EzWeb, ya que no tengo muy claro que componente de la plataforma lo utilizaría, cómo accedería a la información y cómo la utilizaría.Quizás necesitamos discutirlo un poco más o que se aclaren algunos puntos del proyecto, como bien señaláis en el documento. OWL-S y WSMO son iniciativas para la construcción de Servicios Web Semánticos, introducir algo así en EzWeb dispararía la complejidad del proyecto, y no veo su necesidad en una plataforma de mashup. — L. Polo

[editar]

Análisis de servicios

Se distinguen dos tipos de servicios: 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. Atendiendo a los acuerdos establecidos hasta el momento no se tendrán en cuenta los recursos creados por composición de momento.

Los servicios tienen estado interno en forma de variables. Clases: Variable. Propiedades: has_var_state, var_state_defined_in.

NOTA - AH: personalmente creo que no es una buena idea que los servicios y gadgets abran su estado interno o que expongan los datos intercambiados con otros recursos a terceros. Con ello estamos mezclando mecanismos de comunicación diferentes pero... no es fácil dejar fuera decisiones ya implementadas por lo que se ha dejado esta puerta abierta.

Los datos en los mensajes enviados y recibidos por los recursos se exponen a través de variables de sólo lectura en el caso de signals y de variables de lectura/escritura en el caso de los slots. Clases: R_signal_event_output_variable, RW_sloth_input_output_variable. Propiedades: has_signal_output, has_sloth_input, sloth_defined_in, signal_defined_in.

NOTA - AH: insisto en que personalmente es una idea que no me agrada. Por ejemplo, habría que responder de momento a la siguiente pregunta: ¿implica un envio de mensale la modificación de una variable de lectura/escritura?

Se ha incluido el concepto orquestación como medida de precaución para definir posibles marcos de comunicación más complejos. Conceptos: Orchestration. Propiedades: defined_by.

Los servicios envían y reciben mensajes a través de sus signals y sus slots(aunque en esta semántica no se tenga todavía en cuenta), el comportamiento de dicha comunicación es síncrona (si un servicio envía y nadie recibe se bloquea hasta que alguien reciba y viceversa). Esta decisión estaría avalada por los siguientes hechos:

Simplicidad en la implementación.
Sencillez en la gestión/simulación de la concurrencia en entornos nativamente no concurrentes.
Posibilidad de utilizar Pi-cálculo, LTS (Labelled Transition Systems) o simplemente en máquinas de estado finito como mecanismo para dar descripción semántica de todo el sistema y probar propiedades de seguridad (ej. no hay deadlocks) y vivacidad (ej. no hay inanición) en los servicios.

Se acompaña la siguiente imagen de las propiedades que relacionan servicios:

[editar]

Características deseables pero no analizadas

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.

Los servicios de backend encapsulan acceso a servicios legados (como web services, RPCs, APIs, etc.).

NOTA - AH: éste último punto creemos que se recoge en los servicios básicos y en los contenidos

NOTA - AH: ¿es necesario implementar un planificador en el entorno operacional? ¿se sacrificaría mucha expresividad en el caso de no tener concurrencia real? IP: ¿debe delegarse ese trabajo en el navegador? ¿se podría?

NOTA - AH: otra opción para la semántica de servicios es que los servicios tengan una descripción más estática, se comportan como funciones que se ejecutan ante cualquier cambio de sus entradas. Un problema entonces es, por ejemplo, la implementación de bucles (condición de paradas).

[editar]

Formalización de servicios

La formalización de los servicios es parte de la ontología http://babel.ls.fi.upm.es/~angel/ezweb/semantics/ezweb-simple-resources.owl.

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.

[editar]

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.

[editar]

Análisis de gadgets

Por el momento se ha optado por un enfoque poco arriesgado en el que los gadgets son servicios con vista:

Un gadget se diferencia de un servicio en que tiene vista. Por lo tanto, su modelo es el mismo que el de los servicios (por eso la clase gadget se ha derivado de la clase servicio) más el modelado de la vista.

Si el modelo de comunicación de servicios es el de paso de mensajes entonces no es necesario ampliarlo en gadgets con otros métodos de señalización (signaling) que añadirían más complejidad.

La creación de un gadget por composición de otros exige (y es suficiente) que el modelo capture las posiciones relativas de los gadgets que lo componen.