El documento describe la evolución de los datos en la Web, desde datos semiestructurados representados en XML hasta la Web Semántica y el uso de ontologías. Explica los desafíos de la integración de datos provenientes de múltiples fuentes heterogéneas y presenta cuatro posibles soluciones: 1) integración manual, 2) creación de una base de datos unificada, 3) uso de bases de datos federadas y 4) uso de data warehouses. Finalmente, introduce los conceptos de mediadores y wrappers como herramientas clave para lograr la interoperabil

1. Datos en la Web
3º Clase – Interoperabilidad en la Web
Galiano, Sebastián
LCC, UNR
Rosario, 2008

2. Antecedentes:
En principio partimos de conocer como estaban
representados los Datos en la Web y nos
encontramos con algo que desconocíamos o con
lo que nunca habíamos trabajado en Bases de
Datos: los Datos Semiestructurados.
Buscamos un formato de intercambio que
mejorara a HTML, y nos encontramos con una
familia de herramientas para esto llamada XML;
conocimos el lenguaje XPath con su extensión
XPointer (para localizar los datos en la web),
XSL (XSLT + XSL-FO), y XQuery (lenguaje de
consulta para XML).

3. Antecedentes:
Luego descubrimos el término Web Semántica y nos
empezamos a interesar en el mismo. La idea era
agregarle semántica a los datos en la web. Nos
encontramos con RDF. Pero no nos definía
Semántica, sino que mas bien nos definía un
mecanismo simple para describir los recursos de la
web mediante un formato interesante, el uso de
tripletas. Necesitábamos primero mejorarlo, y
encontramos RDF Schema que le añadía algunas
funcionalidades interesantes pero no llegaba a darle la
semántica que queríamos. Luego supimos que
también hay un lenguaje de consulta para RDF y
RDFS, conocimos SPARQL.
Nuestra intención de agregar semántica llego a su fin
cuando descubrimos las Ontologías. También
conocimos el lenguaje estándar para descripción de
ontologías en la web, OWL.

4. Introducción:
Esto nos llevo a, lentamente, comenzar a pensar la web como
una base de datos y no como un conjunto de documentos.
Pero en la web no hay una sola base de datos que represente los
datos, hay varias: Bases de Datos Distribuidas, Bases de Datos
Autónomas, Bases de Datos Semiestructuradas, Bases de Datos
Heterogéneas, etc.
Y los usuarios que la usan también persiguen fines determinados
y específicos, y distintos a la vez.
Dentro de la Web nos encontramos con:
 datos estructurados y semi - estructurados
 modelos relacionales y jerárquicos
 MySQL contra PostgreSQL contra Oracle
 y ni hablar de las diversas y variadas
ontologías y vocabularios

5. Problema:
Se trata de poder formular una sola consulta, y recibir una única
respuesta, de modo que en la preparación de la respuesta
intervengan datos de varias bases de datos.
El problema ahora es la integración de todos estos datos, de toda
esta información. Esto comprende el acceso uniforme a múltiple
fuentes de datos autónomas y heterogéneas, la idea es que el
usuario pueda interactuar con un solo sistema y no tenga que lidiar
con todo lo que vimos hasta acá.
Necesitamos que haya facilidad y optimización de los resultados.
Pero este sistema, esta interfaz que queremos brindarle al usuario
no la tenemos o todavía no la descubrimos.
¿Cómo debería ser?
1. Debería ocultar los detalles de las distintas fuentes
2. Debería interrogar a cada fuente y extraer lo importante de ellas
3. Tendría que integrar toda la información obtenida
4. En base a eso finalmente sacaría una conclusión
5. Y todo esto de la manera mas eficiente posible por supuesto.

6. Primeras Soluciones:
1. Integrar manualmente las respuestas de cada base de datos
consultada por separado. La persona que lo realice debe saber que
bases de datos son accesibles, que datos hay en cada una,
descomponer la consulta en las consultas parciales a cada base de
datos, conocer el modelo de cada base de datos, conocer el lenguaje
de cada base de datos, saber integrar los resultados posibles para
producir el resultado deseado. Es muy poco viable esta solución.
1. Crear una nueva base de datos que integre todos los datos de las
pre - existentes. Tenemos que diseñar la nueva base de datos,
convertir los programas, transferir los datos desde las distintas
bases de datos a la nueva base de datos, preparar y enseñar los
nuevos modos de trabajar a los usuarios. La gestión autónoma de
cada base de datos se pierde en aras de una gestión única.
Estas dos soluciones no nos convencen en absoluto, veamos otras dos.

7. Solución 3:
Construir un sistema federado en el que las bases de datos ínter
operen: integración del acceso.
Superponer un sistema nuevo sobre los SGBDs de las bases
preexistentes.
El nuevo sistema acepta la consulta y devuelve la respuesta, generando
internamente las consultas parciales e integrando sus respuestas.
La existencia de múltiples bases de datos puede ser transparente al
usuario.
Los programas y usuarios preexistentes no se ven afectados.

8. Bases de Datos Federadas:
Las bases de datos federadas son vistas unificadas de bases de
datos independientes.
Aparentan ser una sola base de datos, pero son una colección de
sistemas de bases de datos independientes, cooperativos,
heterogéneos, que son autónomos y que permiten compartir todos o
algunos de sus datos.
Una BDF aparenta ser una BD normal y corriente, pero no tiene
existencia física, es una vista lógica. Se usa una interfaz común pero
no existe un esquema global que describa a todos los datos de las
distintas bases, en su lugar hay varios esquemas unificados, cada
uno describiendo porciones de bases de datos.
El componente principal es el administrador quien recibe una consulta
y la descompone en varias consultas parciales sobre los
componentes.
Las bases de datos federadas son muy importantes en la web, pues
dan una vista común de los datos procedentes de fuentes muy
distintas (Agencias de noticias, portales, foros, periódicos y revistas
electrónicas, etc.)

9. Bases de Datos Federadas:
Un DBS componente de un FDBS puede continuar sus operaciones
locales y al mismo tiempo participar de la federación (participar en la
ejecución de una operación global)
Por esto podemos decir que en las Bases de Datos Federadas se
preserva la autonomía de cada Base de Datos.

10. Bases de Datos Federadas:

11. Bases de Datos Federadas:
DBAs Participantes

12. Bases de Datos Federadas:
Integración débilmente acoplada:
Crear y mantener la federación es responsabilidad de los usuarios a
través de vistas.
Soporta DBS altamente autónomas.
Ventajas: flexibilidad para mapear diferentes semánticas de mismos
objetos en distintos export schemas. Mayor facilidad para manejar
evolución de los componentes.
Desventajas: duplicación de esfuerzos, problema de actualización de
vistas, dificultad en comprender grandes números de export schemas.
Integración Fuertemente acoplada:
DBS tiene el control total sobre la creación y acceso a las DBS.
Soporta uno o más esquemas federados.
Ventajas: las actualizaciones pueden ser soportadas, mantiene
uniformidad en la interpretación de la semántica de múltiples datos
integrados.
Desventajas: violación a autonomía, los DBS negocian que va en los
esquemas de exportación. No soporta evolución dinámica de los export
schemas.

13. Bases de Datos Federadas:

14. Bases de Datos Federadas:
Diferencias con sistemas de bases de datos distribuidas:
Diseño:
Bottom Up en vez de Top Down.
Terminología:
Federado y componente en vez de global y local.
Autonomía:
Autonomía de los DBS. Cada SGBD desconoce al SGBDF.
Transparencias:
Ciertos usuarios perciben una base de datos única.
Otros quieren saber las fuentes.
Usuarios preexistentes continúan accediendo solo a su DBS.

15. Solución 4:
Recordemos como debería ser la solución:
1. Debería ocultar los detalles de las distintas fuentes
2. Debería interrogar a cada fuente y extraer lo importante de ellas
3. Tendría que integrar toda la información obtenida
4. En base a eso finalmente sacaría una conclusión
5. Y todo esto de la manera mas eficiente posible por supuesto.
No se porque pero … esto me recuerda a …
Data Warehouse: “es un deposito de información reunida a partir de
varias fuentes y almacenada en un único lugar según un esquema
unificado.”
Tan solo debemos asociar todas las herramientas que conocimos en las
clases anteriores con cada una de las distintas etapas que tiene el
proceso de creación y ver cuales etapas no podemos cumplimentar
con ellos, para así dedicarnos a buscar nuevas tecnologías que nos
solucionen ese problema.
XML + OWL impactan sobre la migración y limpieza y extracción.
Debemos ver la transformación y carga (partes de ETL)
Conciliación y la validación.

16. Sistemas Interoperables:
Características:
Componentes locales tienen cualquier tipos de datos
Son los sistemas mas débilmente acoplados
No soportan todas las funciones de DBMS

17. Sistemas Interoperables:

18. Sistemas Interoperables:

19. Sistemas Interoperables:

20. Mediadores y Wrappers:
Mediadores:
Es un componente o herramienta de software que:
Hace de conector entre componentes, permitiendo fácilmente la
integración entre información heterogénea. Resuelven problemas de
interoperabilidad
Muestra una única interfaz , o modelo, al usuario.
Descompone las consulta sobre el modelo en subconsultas
específicas y las aplica en cada una de las fuentes.
Brinda por ende una vista global integrada unificando las respuestas
obtenidas de las diversas y variadas fuentes de datos a las que
consulta.

21. Mediadores y Wrappers:
Pero lograr esto no es tan sencillo cuando son varias fuentes y muy
diferentes a la vez …
Una arquitectura de mediación comprende 4 capas:
1. Aplicaciones del Usuario.
1. Mediador.
1. Wrappers (envoltorios).
1. Repositorios de información.

22. Mediadores y Wrappers:
Wrappers:
Los wrappers actúan como interfaces de cada fuente de datos,
proporcionando una (semi) estructura a aquellas fuentes no
estructuradas, o bien mapean la estructura de datos original en la
búsqueda de un patrón común (Data Minning).
Son componentes que traducen las consultas del esquema global al
local y luego vuelven a traducir del esquema local al global para que
el mediador pueda integrarlos mas fácilmente. Vendría a ser algo así
como un traductor.

23. Mediadores y Wrappers:
Wrappers
Sus tareas se pueden resumir en:
Aceptar consultas acerca de la información en las fuentes.

Conseguir las páginas relevantes.

Extraer la información solicitada.

Retornar los resultados.

La construcción de un wrapper incluye:
Identificar la estructura de las fuentes, identificando las secciones
y subsecciones de interés.
Construir un parser o analizador para que trabaje sobre las
páginas fuentes.
Definir la comunicación entre wrapper, mediador y fuentes web.

24. Mediadores y Wrappers:

25. Mediadores y Wrappers:

26. Comparación de Arquitecturas:

27. State of the Art:
Tendencias actuales en los trabajos sobre wrappers:
Buena parte de los trabajos actuales están enfocados hacia lograr la
generación automática de los wrapper a partir de la planificación
inteligente y la definición de reglas de aprendizaje en forma dinámica
en las cuales se tenga como entrada reglas de entrenamiento, reglas
admisibles de extracción y las reglas de búsqueda.
Aprendizaje por ejemplo y prueba
Se ha intentado con estrategias de búsqueda de prefijos y sufijos
cortos hasta ir encontrando los correctos. El aprendizaje es rápido pero
hay problemas con las pérdidas de datos y requiere un alto nivel de
ejemplos.
Aprendizaje por transductores
Reglas contextuales como “Empieza con mayúscula” y “termina con </
a>”

28. State of the Art:
ARIADNA
El proyecto Ariadna se centra en el desarrollo de metodologías y
herramientas que construyen de forma rápida agentes inteligentes,
similares a los wrappers, con el objetivo de unificar vistas de recursos
Web.
Las herramientas permiten la construcción de wrappers que hacen
búsquedas y consultas en fuentes Web como si se tratara de una base
de datos tradicional.
Su estrategia es descomponer Consultas y combinar las respuestas.
Ariadna integra datos de sitios múltiples, integrando datos fuentes
Web semi-estructuradas.
Crea agentes de información y da una visión unificada a diversos
recursos Web.
Permite consultas tipo base de datos convencional, descompone las
consultas y combina las respuestas.

29. State of the Art:
ARIADNA
Componentes:
• Un modelo de dominio del problema
• Una descripción de las fuentes de información en términos del
modelo.
• Wrapper que proveen acceso uniforme a las fuentes de información
permitiendo consultas como si fueran bases de datos relacionales
• Un planificador de consultas que dinámicamente determina la forma
eficiente de procesar una consulta de usuario de acuerdo a las fuentes
de información disponibles. El sistema descompone la consulta en
subconsultas a fuentes de datos individuales.
Desde esta visión se tratan las páginas Web como una fuente de
información que puede ser consultada, por lo cual requiere de un
wrapper que pueda extraer y retornar la información solicitada desde
cada tipo de página.

30. State of the Art:
ARIADNA
Los wrapper de Ariadna poseen:
- Un modelo Semántico
- Un modelo Sintáctico
- Una interfase de usuario orientada a demostración (Demonstration-
oriented user interface DOUI), donde el usuario muestra al sistema
que información extraer desde páginas ejemplos. Bajo la interfaz está
un sistema de máquina de aprendizaje para inducir las reglas
gramaticales.

31. State of the Art:
TSIMMIS:
The Stanford-IBM Manager of Múltiple Information Sources
Como su nombre relacionado en Yiddish, es una mezcla
deliciosa de cosas diversas.
La meta del proyecto de TSIMMIS es desarrollar herramientas
que faciliten la integración rápida de fuentes de información
heterogéneas que pueden incluir datos estructurados y
semiestructurados.
Sus componentes pueden traducir preguntas e información,
extraer datos de la Web y combinar información de diversas
fuentes vía mediador

32. State of the Art:
W4F:
World Wide Web Wrapper Factory
Es un proyecto que genera Wrappers bajo Java.
Su proceso se identifica con las tres siguientes etapas: Recuperación,
extracción y traslación o mapeo. El lenguaje de recuperación especifica
dónde y cómo cargar el documento html.
Una vez recuperado el documentos se convierte en un árbol y se aplican
las reglas de extracción según los datos que se quiera conseguir del
documento.
La información extraída es almacenada en un formato interno basado
en listas anidadas.
Finalmente estas listas son trasladadas al formato final para su
presentación al usuario.
Este proceso es repetido para cada documentos Web.
El proyecto W4F incluye asistentes para cada uno de las fases antes
descritas que nos ayudan a la hora de especificar los datos que se
quiere extraer de una determinada fuente.

33. State of the Art:
TUKWILA
Es un sistema de integración de datos que trata de responder
a las consultas realizadas a diferentes fuentes de datos
autónomas y heterogéneas. Todas las fuentes son trasladadas
a un esquema intermedio común.
El sistema de integración de datos reformula las consultas en
varias consultas sobre las fuentes y posteriormente combina el
resultado de todas en una sola respuesta.
El objetivo de Tukwila es procesar consultas eficientemente de
cadenas de datos en XML

34. State of the Art:
Arquitecturas de Soluciones de optimizaciones Lógicas y
físicas de Consultas en Mediadores de Fuentes web
Denodo Virtual Port es una de estas arquitecturas.
Permite definir un modelo de datos unificado, mediante la
combinación flexible vía SQL de los modelos de datos de las fuentes
individuales.
La potencia de este producto reside en que las nuevas aplicaciones
pueden tener acceso a este modelo unificado mediante un potente
lenguaje de consultas (SQL) como si de una base de datos local se
tratase.
Para ello debe descomponer cada consulta en todas las subconsultas a
efectuar sobre las fuentes implicadas, lanzarlas en paralelo e integrar
los datos obtenidos de los extractores mediante las operaciones
relacionales que se hayan definido.

35. State of the Art:
Mediadores e Interoperabilidad en E-learning
Este es un campo que está en gran crecimiento.
La interoperabilidad es un factor clave en los sistemas de eLearning ya
que permite el intercambio y la reutilización de recursos educativos
que han sido desarrollados en distintas plataformas.
Un Caso práctico es el proyecto ELENA, cuya infraestructura de
interoperabilidad emplea estandartes de eLearning, mediadores
educativos, Wrappers, RDF y ontologías.
Actualmente se evalúa la aplicabilidad del espacio inteligente en el
campo de la educación y se analiza la perspectiva desde el punto de
vista de organizaciones para diseñar espacios inteligentes en este
campo.

36. Bibliografía:
http://jungla.dit.upm.es/~saguirre/publications/virtualEduca2004.pdf
http://www.utp.edu.co/php/revistas/ScientiaEtTechnica/docsFTP/152258397
http://www.tic.udc.es/~mad/publications/jitel2005.pdf
ftp://jano.unicauca.edu.co/cursos/Especializacion/SistDistribuidos/transp/In