De MorfeoWiki

==Planteamiento== *Expondrá en detalle la necesidad de disponer de entornos capaces de extraer y explotar el conocimiento de los usuarios. Presentando las plataformas de Mashup como entornos preferentes para la realización de esta tarea. *Se definirán y evaluarán técnicas de extracción y explotación del conocimiento aplicables en plataformas de Mashup (contexto, etiquetado, configuración, compartición, composición, autoservicio...) *Se especificará la funcionalidad de la plataforma de Mashup ==Introducción== ==Adquisición y Explotación del conocimiento del usuario desde plataformas de Mashup== ===Extracción y Gestión del conocimiento=== ===Plataformas de Mashup como integradores del conocimiento de los usuarios=== ===Métodos de Adquisición de Conocimiento=== ====Etiquetado==== ====Composición guiada por el usuario==== ====Estadísticas de uso...==== ===Explotación del conocimiento en plataformas de Mash-up=== ====Sensibilidad al contexto==== ====Compartición del conocimiento==== ====Automatización de tareas...==== ==Especificación de requisitos una clataforma de Mashup (EzWeb y EzWeb.Lite)==

Tabla de contenidos 1 D 3.1.1 Especificación para la construcción de una plataforma de Mashup sensible al contexto y guiado por el usuario 1.1 Introducción 1.1.1 Definiciones Previas 1.1.1.1 Mashup 1.1.1.2 Recurso (REST) 1.1.1.3 Gadget 1.1.2 Objetivo 1.2 Especificación de Requisitos 1.2.1 Requisitos Generales (o de Arquitectura) 1.2.1.1 Requisitos funcionales 1.2.1.2 Requisitos no funcionales 1.2.2 Requisitos por Módulo 1.2.2.1 Showcase 1.2.2.2 Dragboard 1.2.2.3 Wiring 1.2.2.4 Persistencia 1.2.2.5 Adquisición de conocimiento - Feedback 1.2.2.6 Gestion de Contexto 2 D 3.1.2 Adquisición de conocimiento del usuario y explotación desde entornos Mashup 2.1 Introduccion 2.2 Plataformas de Mashup como integradoras de conocimiento de los usuarios 2.3 Mecanismos de Adquisición de Conocimiento 2.4 Mecanismos de Explotación de Conocimiento 2.5 Arquitecturas Colaborativas Orientadas al Conocimiento 2.5.1 Acceso a recursos unificado 2.5.2 Composición de recursos 2.5.3 Fomentar la innovación y la colaboración a través del catálogo 2.6 Conclusiones 2.6.1 Ventajas de usar Mash-up 2.6.1.1 Ventajas que obtienen las empresas 2.6.1.2 Ventajas que obtienen el desarrollador 2.6.2 Inconvenientes de usar Mash-up

D 3.1.1 Especificación para la construcción de una plataforma de Mashup sensible al contexto y guiado por el usuario

Introducción

En este documento se pretenden definir claramente los requisitos de usuario que debe satisfacer la Plataforma de Mashup.

Definiciones Previas

Mashup

Por Mashup se entiende todo aquel entorno operacional, normalmente web, que pueda combinar distintas fuentes de datos e integrarlas fácilmente en un mismo entorno. De esta manera se pueden obtener entornos avanzados fácilmente, a partir de la composición de elementos más sencillos.

Las plataformas de Mashups se han hecho populares por su utilización en la sindicación de contenidos (RSS), sin embargo no es su única aplicación. Su facilidad de uso, incluso por parte de usuarios inexpertos, y sus capacidades de composición e integración, los hacen especialmente atractivos de cara a obtener todo tipo de entornos operacionales avanzados altamente personalizables. Teniendo en cuenta estas capacidades, podemos catalogar las plataformas de Mashup en tres áreas: Mashups cliente, Mashups de datos, y Mashup empresariales.

Los Mashup cliente son muy conocidos ya que su máximo representante son las aplicaciones del tipo Google Maps o iGoogle. En estas plataformas se combinan elementos sencillos, o gadgtes, que manejan datos de diversa índole en una única interfaz gráfica, obteniendo así una interfaz mucho más completa. Los Mashup de datos en cambio, mezclan datos similares procedentes de diversas fuentes (lectores de feeds RSS como Netvibes, etc), pudiendo incluso generar nuevos flujos de datos (Yahoo Pipes).

Por su parte, los Mashup empresariales son una mezcla de ambos, se centran tanto en la agregación como en la presentación, y pueden incluso incorporar funciones colaborativas, obteniendo así un resultado final que se adapta a las necesidades de los entornos empresariales. En este area es donde se ubicaría EzWeb.

Recurso (REST)

Los componentes de REST realizan acciones en un recurso usando una representación que capture el estado actual o previsto de un recurso y transfiriendo la representación entre los componentes

Un recurso bajo el punto de vista de la filosofía REST, es una representación de información, generalmente un documento XML aunque puede ser cualquier otro tipo de documento, identificado unívocamente por una URI, y con el cual se puede interactuar mediante el protocolo HTTP.

Las distintas acciones que se pueden llevar a cabo sobre un recurso vienen determinadas por el método HTTP utilizado, de esta manera se suele utilizar:

• POST: Crea una nueva representación de un recurso asociada a la URI
• GET: Recupera la representación del recurso
• PUT: Modifica la representación del recurso
• DELETE: Elimina el recurso

De esta manera, para manipular recursos los componentes de la red (clientes y servidores) se comunican a través de un interfaz estándar (HTTP) e intercambian representaciones de estos recursos (documentos que descargan y se envían) sin necesidad de aplicaciones añadidas cómo ocurre en los sistemas basados en Web Services. Esto además, permite que un usuario final tenga un total acceso a los recursos REST simplemente con un navegador.

Gadget

Un gadget es un elemento sencillo que puede ser incorporado a un entorno de Mashup, y por tanto suele depender de esta.

Estos elementos pueden estar ligados a una o varias fuentes de datos permitiendo la interactuación con otros sistemas. Además, permiten llevar a cabo todo tipo de acciones: visualización de datos, intercambio de datos entre distintos gadgets, generación/recepción de datos, filtrado de datos, etc.

En el contexto EzWeb, un gadget está formado por el propio código del gadget, y por un template que define su comportamiento y su interactuación con el medio. Para ello, el template debe recoger la siguiente información:

• Los eventos de usuario que admite y el manejador del mismo.
• Los datos de carácter persistente.
• Los parámetros de personalización
• La información básica del gadgte (autor, versión, descripción, etc)

Objetivo

A tenor de lo dispuesto anteriormente, se desea desarrollar un entorno empresarial avanzado basado en las plataformas de Mashup, que permita la fácil composición e integración de un mismo entorno operativo, a partir de la composición e interacción de componentes sencillos (a partir de ahora Gadgets). Esta plataforma estará destinada a usuarios no expertos y puede que sin conocimientos técnicos.

Especificación de Requisitos

Requisitos Generales (o de Arquitectura)

---

Ver D 1.1.1 Documento de Requisitos de Usuario

Se detallan a continuación los requisitos que debe satisfacer la arquitectura de la plataforma.

Requisitos funcionales

• Compartir el conocimiento (Web 2.0): Los usuarios finales deben contar con la capacidad de crear y compartir conocimiento, que se materialice en la capacidad de construir nuevos recursos y publicarlos en la red, así como intercambiar experiencias con otros, aprendiendo juntos y acelerando de este modo tanto la incorporación constante de innovaciones como la mejora de la productividad.

• Adquisición y explotación del conocimiento: Se debe poder adquirir, gestionar, compartir y explotar el conocimiento de sus usuario. Esta información será recopilada de tres areas fundamentales:

• Conocimiento de Usuario
• Conocimiento de Contexto
• Conocimiento de Uso

Ver D.3.1.2 Adquisición de conocimiento del usuario y explotación desde entornos Mashup

• Cache de Gadgets: La configuración del entorno se hará en base a recursos o gadgets disponibles en la red. La plataforma accederá a estos recursos y guardará una copia local de los mismos. A partir de ese momento, las posteriores cargas en la plataforma y toda la gestión se llevará a cabo a partir de la copia local. Se posibilita de esta manera un posible comportamiento offline relacionado con EzWeb.Lite

• Independencia Tecnológica y de ubicación: La tecnología utilizada en la implementación de los gadgets, así como su ubicación, no serán un impedimento para poder utilizarlos en la plataforma, siempre y cuando estos estén disponibles mediante HTTP y tengan asociado un template válido.

• API RESTful : Todos los recursos que componen la Plataforma, así como las interfaces de los distintos módulos, deberán tener al menos una interfaz RESTful (ver Recurso en #Definiciones_Previas)

Requisitos no funcionales

• Altamente Personalizable: Los usuarios finales deben contar con la máxima autonomía y capacidad de personalización en relación con la configuración de su entorno operativo, como resultado de localizar, elegir, personalizar y combinar de manera flexible y dinámica (siguiendo un modelo de autoservicio o filosofía tipo IKEA) recursos disponibles en la red.

• Dependencia de Contexto: El entorno operacional del usuario está ligado al contexto, es su espacio personal de trabajo y ha sido configurado para satisfacer las necesidades particulares de cada usuario. Por tanto, la interacción debe adaptarse y ser relevante al contexto, dando al término contexto el significado más amplio posible, de manera que comprenda elementos tales como el contexto del usuario (conocimiento, perfil, preferencias, idiomas, información sobre las redes sociales a las que el usuario pertenece, etc.) o el contexto de utilización (características estáticas y dinámicas del dispositivo usado para el acceso, localización geográfica y de tiempo, la conexión de banda ancha, etc.) y teniendo en cuenta tanto la variabilidad del contexto como la movilidad de los usuarios.

• Potenciar la Usabilidad: Se deberá facilitar al máximo el uso de la plataforma. En este sentido, el usuario sólo necesitará un navegador web (p.e. Firefox) para poder disfrutar plenamente de toda la funcionalidad de la plataforma. Además no será necesario tener un conocimiento técnico avanzado, dado que la interfaz será lo más intuitiva y sencilla posible, sin penalizar por ello las capacidades funcionales de la misma.

Requisitos por Módulo

---

La Arquitectura de la Plataforma se compone de tres módulos funcionales, claramente diferenciados, y cuyos requisitos se detallan a continuación

FIXME: ¿Son tres o son seis?

Showcase

Será el encargado de llevar la gestión de los gadgets que han sido incorporados en la plataforma, por tanto deberá:

• Actuar de repositorio y cache personal de gadgets,
• Permitir llevar a cabo una gestión básica de gadgets mediante las siguiente operaciones:

• Añadir gadgets a partir de los disponibles en los catálogos alojados en la red
• Recuperar la información local del gadget
• Etiquetar y valorar gadgets
• Actualizar el contenido de un gadget desde la red
• Eliminar un gadget de la Plataforma. Además debe permitir seleccionar y agregar gadgets al entorno operacional (Dragboard).

Dragboard

Deberá gestionar el entorno operacional del usuario. En este sentido deberá permitir:

• Añadir y maquetar gadgets en un mismo entorno operacional. En este sentido el entorno debe ser altamente personalizable, permitiendo:

• Configurar el tamaño y la forma de las instancias de gadgets

• Se permite la multi-instanciación de un mismo gadget. Para ello es necesario diferenciar entre las distintas instancias de gadgets en ejecución relativas a diferentes usuarios y gadgets. De esta manera se posibilita:

• Que un mismo gadget sea utilizado por varios usuarios
• Que pueda haber varias instancias de un mismo gadget en un mismo entorno operacional.

• El entorno operacional deberá mostrarse como un grid configurable (layout) donde se ubicarán los gadget instanciados
• Ofrecer una interfaz adecuada para la modificación de las preferencias de usuario. Dichas preferencias deberán ser persistentes.

Wiring

Será el encargado de la comunicación entre gadgets. Para ello debe permitir:

• Crear flujos de datos mediante wires entre gadgets
• Generar las conexiones tanto automáticamente como de manera manual por parte del usuario
• Establecer conexiones a partir de "friend-codes" (orientadas a datos)
• El modelo de comunicación será una pizarra con publish/subscribe
• El template del gadget determina que datos son los utilizados para establecer las conexiones
• Tanto las conexiones como los datos deben ser persistentes
• De debe dar soporte al concepto de filtro asociado al flujo de datos

Persistencia

Se encargará de centralizar las operaciones de persistencia haciendo de interfaz con los sistemas de back-end. En este sentido se deberá:

• Almacenar el estado de los gadgets y la plataforma por cada usuario
• Permitir una gestión básica de usuarios (añadir, eliminar, login, etc)

Adquisición de conocimiento - Feedback

Actuará como recopilador del conocimiento que se desprende de la interactuación del usuario con la plataforma, o conocimiento de uso. El resto de módulos deberán proporcionar toda la información posible acerca de su interactuación con el usuario, como puede gadgets utilizados, etiquetado de los gadgtes, valoración de gadgtes, tiempo en uso, número de actualizaciones llevadas a cabo, búsquedas realizadas, etc.

La información se representará mediante técnicas ligeras y se formalizará según estándares. Posteriormente este conocimiento se explotará y compartirá de cara a generar automatismos que mejoren y adapten la plataforma deinamicamente a las necesidades de los usuarios.

Gestion de Contexto

Será el encargado de analizar la información que el usuario genera para determinar el contexto de aplicación de usuario, el cual condicionará las siguientes acciones que puede realizar este módulo:

• Realizar sugerencias al usuario acerca de recursos/gadgets que puede utilizar
• Búsqueda guiada de recursos

D 3.1.2 Adquisición de conocimiento del usuario y explotación desde entornos Mashup

Introduccion

Considerar al usuario como el eje central de los sistemas es el cambio distributivo que la filosofía Web2.0 está impregnando al mundo del software. Aprender del usuario, darle protagonismo y dejarle innovar mediante mecanismos sencillos y visuales, conduce a mejorar, inevitablemente, el proceso de desarrollo de software y la experiencia de usuario. Siguiendo este enfoque, surge la potente figura del "Knowledge worker", visión Web2.0 del usuario tradicional, capaz de aportar valor añadido a los sistemas.

Sin embargo, potenciar las capacidades creativas del usuario sin prestar atención a la adquisición, compartición y explotación del conocimiento generado no permite alcanzar todo el potencial que esta filosofía persigue. La colaboración y compartición de conocimiento se erigen como el pegamento que hace que todo encaje.

A lo largo de este entregable, se describen formas e instrumentos de colaboración entre "knowledge workers", de tal forma que sea fácil adquirir y explotar mediante mecanismos colaborativos el conocimiento generado en entornos de Mashup de nueva generación.

Plataformas de Mashup como integradoras de conocimiento de los usuarios

La creciente popularidad de las plataformas de Mashup actuales se basa en potenciar las capacidades de los usuarios. Probablemente, la capacidad de crear y personalizar totalmente sus propios interfaces de interacción de una manera visual y sencilla, sea la característica más atractiva para los usuarios. Estas nuevas capacidades, permiten recoger sus gustos, preferencias y deseos en cuanto a personalización de interfaces se refiere. Por otro lado, la utilización de la plataforma proporciona conocimiento acerca de cómo los usuarios resuelven los problemas mediante la propia plataforma.

Este enfoque eminentemente flexible, creativo, multiusuario y colaborativo de las plataformas de Mashup, hace que actúen como integradoras naturales del conocimiento de la comunidad de usuarios que la utiliza. Analizando el tipo de conocimiento que se gestiona en la plataforma EzWeb, se obtiene la siguiente clasificación de conocimiento:

La siguiente figura muestra la distribución de los tres tipos de conocimientos detectados en la arquitectura de la plataforma EzWeb.

Por todo lo anterior, adquirir y explotar adecuadamente dicho conocimiento debe ser una prioridad en las modernas plataformas de Mashup.

Mecanismos de Adquisición de Conocimiento

El enfoque de la plataforma Morfeo-EzWeb, promueve una adquisición de conocimiento informal, con mecanismos sencillos y cercanos al usuario, de tal manera que se fomente la participación de los mismos. De acuerdo a la clasificación del conocimiento detectado en la plataforma EzWeb, se ha establecido una relación entre el tipo de conocimiento y un mecanismo ligero de gestion de conocimiento.

• Tagging (conocimiento de usuario). Un usuario de la plataforma EzWeb debe ser capaz de caracterizar mediante etiquetas todo elemento disponible en la misma. Además, para lograr una caracterización más útil para el usuario, se podrán valorar colaborativamente dichos recursos.
• Profiling (conocimiento de contexto). Todo elemento de la plataforma tiene asociado un contexto o descripción contextual que lo caracteriza. Dicho contexto puede ser enriquecido por contribuciones del usuario o procesos de inferencia automáticos.
• Usage tracking (conocimiento de uso). Toda acción significativa que el usuario realiza sobre la plataforma, genera conocimiento que posteriormente será explotado.

Sin embargo, estos métodos ligeros de gestión de conocimiento porporciona resultados en bruto y potencialmente de poca calidad, haciendo imposible realizar potentes procesos de inferencia sobre ellos. Por lo tanto, se necesita una representación más formal que refine el conocimiento adquirido, permitiendo razonar sobre él y obtener resultados útiles que repercutan sobre el usuario.

La siguiente figura profundiza en las relaciones existentes entre los procesos ligeros de gestión de conocimiento y ciertas tecnologías formales y más tradicionales de representación y gestión de conocimiento.

Mecanismos de Explotación de Conocimiento

Explotar y compartir adecuadamente el conocimiento capturado por la plataforma puede ser la característica que aporte un mayor valor añadido a los usuarios de una plataforma de Mashup de nueva generación. Los "knowledge workers" cooperan colaborativamente en busca de un bien común mediante la compartición de conocimiento. Todos los usuarios de la comunidad pueden beneficiarse de manera efectiva de las mejoras encontradas por los usuarios más innovadores, promoviendo una especia de selección natural, de manera que solo los recursos más utiles sobreviven (ya que la gente substituirá, sin paliativos, los menos útiles por otros más prometedores)

El conocimiento que comparten y explotan colaborativamente los "knowledge workers" proporcionan interesantes características a la plataforma:

• Sensibilidad al contexto. Existen procesos dentro de la plataforma que pueden enriquecerse de la información contextual tanto del usuario como de los recursos involucrados. Todo proceso relacionado con la personalización de los resultados de una operación, es suceptible de ser potenciada con información contextual. Ejemplos claros son los procesos de búsqueda de recursos en base a mi información contextual (recursos que ya tengo en mi entorno operativo, recursos que usan mis amigos, etc ) o la visualización de interfaces adaptados a mi contexto (acceso en horas de trabajo, tipo de fuente favorita, idioma materno, etc)

• Explotación de la caracterización de recursos por parte de los usuarios. Los usuarios pueden caracterizar, de manera genérica y colaborativa, cualquier recursos en base a mecanismos folksonómicos. En concreto, la explotación de dichas caracterizaciones permitirá realizar procesos de búsqueda y descubrimiento mucho más efectivos. Además, cada recurso es valorado por los usuarios, de forma que la plataforma podrá recomendar recursos en base a la opinión de los usuarios.

• Compartición de soluciones. El usuario puede publicar sus soluciones e innovaciones para que sean incorporadas y utilizadas por el resto de los usuarios de la comunidad. Probocando, por tanto, un ritmo constante de innovación en soluciones. Por otro lado, la plataforma de Mashup EzWeb explota el conocimiento de uso adquirido de manera automática y permite compartir de manera eficiente las mejores prácticas o tendencias detectadas a partir del uso de la plataforma.

Arquitecturas Colaborativas Orientadas al Conocimiento

Todos los conceptos descritos en este entregable son lo suficientemente innovadores y alejados del enfoques tradicional como para necesitar ser incorporados desde la definición de la arquitectura. La arquitectura colaborativa orientada al conocimiento propuesta para EzWeb puede verse en la siguiente figura:

Acceso a recursos unificado

Tradicionalmente los sistemas exportan al exterior, siguiendo una filosofía SOA, un conjunto de servicios que recubren el back-end subyacente. Sin embargo, EzWeb ha redefinido SOA para centrarlo en el usuario final (considerado como cliente de servicios) proporcionando una capa front-end RESTful, proporcionando una capa de recursos uniforme accesible directamente por el usuario a través de invocaciones HTTP, como se ve en la parte inferior de la figura.

La arquitectura pretende fomentar la combinación por parte del usuario final de recursos, en base a unos interfaces visuales y fáciles de manejar. Estos recursos pueden ser enriquecidos semánticamente mediante tagging o descripción colaborativa en base a una Wiki.

El concepto fundamental, sobre el que gira alrededor toda la arquitectura descrita, el de recurso. Un recurso no es más que un simple componente descrito mediante el estilo arquitectónico REST. Cada recurso tiene una URI y responde a las primitivas HTTP (get, post, put y delete) de tal manera que se proporciona un acceso total a los sistemas de una forma uniforme.

Disponer de una interfaz de acceso uniforme permite al usuario final componer fácilmente recursos entre sí, buscando la solución que mejor se adapta a su problemática concreta. El catálogo es el elemento central que permite la localización eficiente de recursos, fomentado la creación de soluciones instantáneas siguiendo la filosofía DIY ("do it yourself") inherente a los Mashups. Este proceso se lleva a cabo de una manera totalmente visual, de tal manera que no sea necesario ser un experto en TI.

La siguiente clasificación de los recursos proporciona a los usuarios finales un entorno de desarrollo de soluciones simple y genérico:

• Fuentes de Datos, que alimentan a la aplicación de Mashup.
• Operadores, que transforman los datos de la aplicación.
• Gadgets, que visualizan los interfaces de interacción humana a los usuarios.

Composición de recursos

Tal y como se ilustra en la siguiente figura, cuando se crea un mashup de recursos, los "knowledge workers" necesitan resolver sus interdependencias de dos formas diferentes. Por un lado, se interconectan las salidas de recursos heterogéneos (típicamente fuentes de datos u operadores) a las entradas de otros recursos (operadores), creando de esta manera una cadena de transformación de datos (piping). Por otro lado, es necesario interconectar gadgets entre sí, de tal manera que la experiencia de usuario de una aplicación de Mashup sea comparable a la de una aplicación de escritorio (wiring).

Gracias a estas técnicas de composición de recursos, se hace disponible a los usuarios un universo dinámico de recursos que potencia la creación de un entorno de constante innovación.

Fomentar la innovación y la colaboración a través del catálogo

El enorme número de recursos creados por los knowlegde workers a través de la colaboración diaria constituye un universo de recursos potencialmente infinito, caracterizado por un rápido ritmo de aparición. Si solo se proporcionase un servicio tradicional de búsqueda de recursos, sería cada vez más fácil para los knowledge workers encontrar los recursos que necesitan para crear los Mashup que quieren.

NOTA - ¿no será "difícil" en lugar de "fácil"?

La arquitectura EzWeb solventa estos requisitos mediante una perspectiva Web2.0, proporcionando un catálogo de recursos gestionado por la comunidad de usuarios de la plataforma. Los knowledge workers disponen de herramientas altamente colaborativas como Wikis y tagging, junto con potentes capacidades de búsqueda por recomendación para localizar o incluso descubrir recursos de interés.

El catálogo presenta el conocimiento capturado por la plataforma de Mashup para componer recursos (incluyendo pipes, operadores y Mashups) de forma gráfica y usable. Las típicas interacciones entre los knowledge workers y el catálogo, se muestran en la siguiente figura.

Conclusiones

En este apartado, como conclusiones, se tratan las ventajas e inconvenientes de realizar un sitio web que permita combinar datos o servicios a terceros para crear una nueva aplicación. Las ventajas estan divididas en dos subapartados . En primer lugar las ventajas que obtiene las empresa al permitir esto, y en segundo lugar las que obtiene el desarrollador.

Ventajas de usar Mash-up

Ventajas que obtienen las empresas

• Mejora del control de usuarios, se obtienen, directamente y con una mayor precisión, las estadísticas de los usuarios que acceden a sus datos/servicios y para qué los utilizan.

• Nuevas aplicaciones (I+D). Se realizan aplicaciones novedosas a bajo coste por que no debes pagar a nadie, ya que las crearán los propios usuarios. Aumenta considerablemente la creatividad. Y como la inversión es menor, el riesgo también lo es.

• Se consigue publicidad al poder estar en varias aplicaciones, el nombre de la compañía, la url, etc, evidentemente esto es publicidad.

• Se incrementa el número de visitas al entrar por diferentes sitios, las visitas se multiplican. Es la misma política que la de la anterior ventaja.

Ventajas que obtienen el desarrollador

La principal ventaja es que ahora los usuarios finales y los programadores son un grupo. Trabajan juntos en la elaboración de nuevas aplicaciones. Con lo que conseguiremos una mayor compenetración. Con lo que conseguiremos un mayor nivel de aplicaciones con pocos recursos, ya que se utilizan los recursos de otros sitios que se han generado previamente.

Para terminar decir que esta nueva filosofía reune la creatividad (del usuario final) el know-how (del programador) y la reutilización (del mash-up).

Inconvenientes de usar Mash-up

Aunque, es verdad, que hay más ventajas que inconvenientes, no todo iba a ser perfecto, no estamos en un mundo de color rosa. Y he aquí las principales deficiencias/inconvenientes:

• Anuncios no deseados, de la misma manera que es una ventaja para la empresa, puede ser un inconveniente para el publico en general cansado de tanta publicidad.

• Dependencia de los proveedores al usar gadgets de otros, estamos totalmente acoplados a ellos. Esto dejaría de ser un inconveniente si nuestro proveedor nos garantiza que siempre va a existir ese servicio, y que no va a cambiar ( o cambiar conservando compatibilidades)

• La propiedad intelectual, el copy right, es más difícil de preservar.

• Se necesita una mayor capacidad tecnológica, al tener por ejemplo que hacer peticiones a varios servicios. Y esto con la (poca) amplitud de la banda ancha española es un problema.