integraciÓn de aplicaciones w - lsi.us.es · integraciÓn de aplicaciones web ### automatizaciÓn...

INTEGRACIÓN DE APLICACIONESWEB

###

AUTOMATIZACIÓN DE LA NAVEGACIÓN Y EL

RELLENADO DE FORMULARIOS DE BÚSQUEDA DE LA

HIDDEN WEB

CARLOS RIVERO

UNIVERSIDAD DE SEVILLA

MEMORIA DE INVESTIGACIÓNDR. DAVID RUIZ & DR. RAFAEL CORCHUELO

SEPTIEMBRE, 2008

First published in September 2008 byThe Distributed GroupETSI InformáticaAvda. de la Reina Mercedes s/nSevilla, 41012. SPAIN

Copyright c© MMVIII The Distributed Grouphttp://[email protected]

In keeping with the traditional purpose of furthering science, education and research,it is the policy of the publisher, whenever possible, to permit non-commercial use andredistribution of the information contained in the documents whose copyright theyown. You however are not allowed to take money for the distribution or use of theseresults except for a nominal charge for photocopying, sending copies, or whichevermeans you use redistribute them. The results in this document have been tested ca-refully, but they are not guaranteed for any particular purpose. The publisher or theholder of the copyright do not offer any warranties or representations, nor do theyaccept any liabilities with respect to them.

Categorías (ACM 1998): H.3.3 [Information Search and Retrieval]: Information fil-tering, Query formulation, Retrieval models, Search process; H.5.3 [Group and Or-ganization Interfaces]: Web-based interaction; H.5.2 [User Interfaces]: Graphical userinterfaces (GUI), Interaction styles (e.g., commands, menus, forms, direct manipula-tion); H.5.4 [Hypertext/Hypermedia]: Navigation, User issues.

Financiación: Plan Nacional de I+D+I (expediente TIN2007-64119) y la Orden deIncentivos de la Junta de Andalucía (expediente P07-TIC-02602).

http://www.tdg-seville.info

[email protected]

Índice general

Agradecimientos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IX

Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XI

I Contexto de investigación

1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.1 ¿Qué es la hidden Web? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.2 Accediendo a la hidden Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.3 IntegraWeb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.4 Hipótesis y cuestiones de investigación . . . . . . . . . . . . . . . . . . . . . . 101.5 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141.6 Estructura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

II Estado del arte

2 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.2 Organización del estudio del estado del arte . . . . . . . . . . . . . . . . . 202.3 Protocolo de revisión de la bibliografía . . . . . . . . . . . . . . . . . . . . . . 222.4 Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3 Acceso a la hidden Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.2 Características de crawling y metasearch . . . . . . . . . . . . . . . . . . . . 273.3 Propuestas de tipo crawling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

II Índice general

3.3.1 HiWE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.3.2 DeepBot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.3.3 Propuesta de Da Silva et al. . . . . . . . . . . . . . . . . . . . . . . . . . . 323.3.4 Otras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.4 Propuestas de tipo metasearch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353.4.1 Metaquerier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353.4.2 Propuesta de Meng et al. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

3.5 Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4 Modelado de formularios de búsqueda . . . . . . . . . . . . . . . 414.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424.2 Problemas derivados del modelado . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.2.1 Extraer etiquetas de campos . . . . . . . . . . . . . . . . . . . . . . . . . . 444.2.2 Identificar campos obligatorios . . . . . . . . . . . . . . . . . . . . . . . 454.2.3 Descubrimiento de atributos . . . . . . . . . . . . . . . . . . . . . . . . . 454.2.4 Establecimiento de correspondencias semánticas . . . . . . . . 464.2.5 Identificar información semántica avanzada . . . . . . . . . . . . 474.2.6 Relaciones lógicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484.2.7 Extraer capacidad de consulta . . . . . . . . . . . . . . . . . . . . . . . . 49

4.3 Propuestas de modelado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494.3.1 Chang et al. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504.3.2 Meng et al. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 574.3.3 Álvarez et al. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 644.3.4 Garcia-Molina et al. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 714.3.5 Otras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

4.4 Framework de comparación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 804.5 Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

5 Lenguajes de consulta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 855.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 865.2 RDF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 865.3 RQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 895.4 RDQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 915.5 SeRQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 915.6 SPARQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 935.7 Otros lenguajes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 945.8 Framework de comparación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 945.9 Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

Índice general III

6 Herramientas para el rellenado y la navegación . . . . . . . . 976.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 986.2 Ejemplo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 986.3 Watir, Watij y Watin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 996.4 Selenium . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1026.5 HTTPUnit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1026.6 iMacros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1036.7 Otras herramientas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1046.8 Framework de comparación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1056.9 Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

III Consideraciones finales

7 Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1117.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1127.2 Modelado de formularios de búsqueda (CI1.1) . . . . . . . . . . . . . . 1127.3 Lenguajes de alto nivel (CI2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1127.4 Herramientas para el rellenado y navegación (CI3) . . . . . . . . . . . 1137.5 Otras cuestiones y trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

IV Apéndices

A Implementación de un enquirer . . . . . . . . . . . . . . . . . . . . 117A.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118A.2 Arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118A.3 Rellenado de formularios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118A.4 Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

B Ejemplo motivador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121B.1 Ejemplo de estudio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122B.2 Bancos de pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124B.3 Formularios de búsqueda de la hidden Web . . . . . . . . . . . . . . . . . 127B.4 Código fuente del formulario de ejemplo . . . . . . . . . . . . . . . . . . . 128

Bibliografía . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

IV Índice general

Índice de figuras

1.1 Visión conceptual de la hidden Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.2 Esquema de la arquitectura de IntegraWeb . . . . . . . . . . . . . . . . . . . . . . 101.3 Visión de la hidden Web como un esquema global de datos . . . . . . . . 141.4 Rellenado de formularios con una consulta de ejemplo . . . . . . . . . . . . 15

2.1 Organización del estudio del estado del arte (mapa mental) . . . . . . . . 21

3.1 Interacción de un usuario con un formulario de búsqueda . . . . . . . . . 293.2 Interacción de un crawler con un formulario de búsqueda . . . . . . . . . 303.3 Pasos para construir un agente que acceda a la hidden Web . . . . . . . . 333.4 Arquitectura de Metaquerier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.1 Conjuntos de atributos de ejemplo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504.2 Extracción de capacidad de consulta de un formulario . . . . . . . . . . . . 514.3 Producciones y patrones visuales de la gramática 2P . . . . . . . . . . . . . . 524.4 Diferencias entre propuestas tradicionales y SSM . . . . . . . . . . . . . . . . . 534.5 Ejemplo de fragmentos de un formulario . . . . . . . . . . . . . . . . . . . . . . . . 564.6 Ejemplo de extracción de capacidad de consulta . . . . . . . . . . . . . . . . . . 574.7 Correlaciones entre atributos de los esquemas de ejemplo . . . . . . . . . 574.8 Esquema de la extracción del modelo de un formulario . . . . . . . . . . . 604.9 Modelo de Meng et al. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 634.10 Modelo del formulario de ejemplo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 644.11 Atributos del formulario de ejemplo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 654.12 Atributos del formulario de ejemplo (continuación) . . . . . . . . . . . . . . . 664.13 Grupos del primer paso de la búsqueda de correspondencias . . . . . . 664.14 Grupos finales de la búsqueda de correspondencias . . . . . . . . . . . . . . . 674.15 Ejemplo de definición de dominio para venta de libros . . . . . . . . . . . . 684.16 Esquema y extracción de etiquetas de formulario de ejemplo . . . . . . . 704.17 Asignación de atributos sobre el formulario de ejemplo . . . . . . . . . . . 71

VI Índice de figuras

4.18 Ejemplo de formulario en PDA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 724.19 Campos del formulario de ejemplo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 754.20 Etiquetas y valores del formulario de ejemplo . . . . . . . . . . . . . . . . . . . . 764.21 Comparativa entre Freire et al., Chang et al. y Meng et al. . . . . . . . . . . 80

5.1 Ejemplo de consulta SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 865.2 Ejemplo de grafo RDF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 875.3 Tripletas RDF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 875.4 Ejemplo de RDFS y su relación con RDF . . . . . . . . . . . . . . . . . . . . . . . . . 885.5 Ejemplo de consultas básicas RQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 905.6 Ejemplo de consultas RQL tipo SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 905.7 Ejemplo de consultas RQL sobre esquema . . . . . . . . . . . . . . . . . . . . . . . 915.8 Ejemplo de consultas RDQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 925.9 Ejemplo de consulta SeRQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 925.10 Ejemplo de consulta simple SPARQL . . . . . . . . . . . . . . . . . . . . . . . . . . . 935.11 Ejemplo de consulta complejas SPARQL . . . . . . . . . . . . . . . . . . . . . . . . . 94

6.1 Ejemplo de rellenado de formularios con Watir . . . . . . . . . . . . . . . . . . 1006.2 Ejemplo de rellenado de formularios con Watij . . . . . . . . . . . . . . . . . . 1016.3 Ejemplo de rellenado de formularios con Watin . . . . . . . . . . . . . . . . . 1016.4 Ejemplo de rellenado de formularios con Selenium IDE . . . . . . . . . . 1036.5 Ejemplo de rellenado de formularios con HTTPUnit . . . . . . . . . . . . . 1046.6 Ejemplo de rellenado de formularios con iMacros . . . . . . . . . . . . . . . 105

A.1 Arquitectura de la implementación . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119A.2 Diagrama de actividades de la implementación . . . . . . . . . . . . . . . . . 119

B.1 Formulario de ejemplo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122B.2 Explicación del formulario de ejemplo . . . . . . . . . . . . . . . . . . . . . . . . . 124B.3 Formularios de búsqueda de libros . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127B.4 Formularios de búsqueda de música . . . . . . . . . . . . . . . . . . . . . . . . . . . 128B.5 Formularios de búsqueda de DVDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

Índice de tablas

4.1 Comparativa de propuestas de modelado de formularios (1) . . . . . . . 824.2 Comparativa de propuestas de modelado de formularios (2) . . . . . . . 82

5.1 Comparativa de lenguajes de consulta RDF . . . . . . . . . . . . . . . . . . . . . . 95

6.1 Comparativa de herramientas comerciales estudiadas . . . . . . . . . . . . 106

B.1 Número de aplicaciones Web y de formularios de TEL-8 . . . . . . . . . 125B.2 Número de formularios de BAMM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

VIII Índice de tablas

Agradecimientos

A David Ruiz, Rafael (Corchuelo y Z. Frantz), José Luis (Arjona y Álva-rez), Pablo Palacios y Francisco Roche por sus comentarios, consejos,

reuniones, discusiones... en general, por todo su trabajo.

A A. Jiménez, E. Velázquez y S. Rodríguez (“los chicos del master”) por sutrabajo Form Fillers and Navigators.

A MJ, la Familia y amigos por aguantarme y apoyarme.

X Agradecimientos

Resumen

V arios estudios afirman que las aplicaciones pertenecientes a la hiddenWeb contienen más información y de más calidad que las pertenecien-

tes a la surface Web. Recientemente, Google ha mostrado interés en la hiddenWeb haciendo referencia a su importancia y a cómo acceder a la informaciónallí contenida.

Para acceder a la información almacenada en la hidden Web hay que em-plear los puntos de entrada que ofrecen las aplicaciones. Estos puntos de en-trada pueden consistir en Servicios Web que exportan la funcionalidad. A ve-ces, las aplicaciones carecen de estos Servicios Web por motivos tecnológicoso de negocio. Las aplicaciones cuya funcionalidad no se expone con ServiciosWeb son denominadas Aplicaciones Web No Desmantelables.

En el acceso e integración de información de Aplicaciones Web No Des-mantelables es necesario simular, de manera programática, interacciones so-bre la interfaz de usuario. En el caso de aplicaciones de la hidden Web, estainterfaz consiste en un formulario de búsqueda donde el usuario rellena unaserie de campos para especificar su consulta y, una vez enviado, la aplicaciónproporciona una respuesta de error o un listado de resultados.

Nuestra investigación gira en torno a cómo rellenar formularios recibiendouna consulta de usuario especificada en un lenguaje de alto nivel (tipo SQL) ycómo navegar, desde la página que se proporciona como resultado del envíodel formulario, hasta los objetos de interés.

Los principales problemas a resolver en el rellenado de formularios consis-ten en transformar el formulario, pensado para la interacción con un usuario,en un modelo que permita ser procesado automáticamente. Otro problema esdecidir si una consulta es viable al ser ejecutada sobre un formulario de bús-queda. Los problemas asociados a la navegación consisten, principalmente, enclasificar de manera automática las páginas de resultados: listados de objetos opáginas de error. Otro problema consiste en alcanzar la información de interésnavegando por los enlaces ofrecidos.

XII Resumen

Parte I

Contexto de investigación

Capítulo 1

Introducción

This is information retrieval not information dispersal.

Jack Lint, Brazil, 1985

E n este capítulo hacemos una breve introducción a la hidden Web ex-poniendo sus principales características. Damos unas pinceladas de

cómo acceder a la hidden Web de manera automática para extraer la infor-mación de interés y repasamos la arquitectura de referencia IntegraWeb. Es-tablecemos nuestra hipótesis describiendo el escenario de partida. De nues-tra hipótesis se desprenden una serie de cuestiones de investigación que sonpresentadas y analizadas. Por último, establecemos los objetivos de nuestrainvestigación y de esta memoria así como su estructura.

4 Capítulo 1. Introducción

Barnes & Noble

Amazon

Fnac

BooksExample

Figura 1.1: Visión conceptual de la hidden Web.

1.1. ¿Qué es la hidden Web?

La hidden Web (o deep Web) es aquella parte de la Web que no está ac-cesible por los motores de búsqueda generales debido a que, las páginas quela componen, son creadas dinámicamente al efectuar una consulta sobre unaaplicación Web [5]. Esta definición la matizaremos más adelante, algunos mo-tores de búsqueda sí son capaces de indexar páginas de la hidden Web, porejemplo, la página principal de las publicaciones de un autor almacenadas enDBLP. En la Figura §1.1 puede verse una visión conceptual de la hidden Web.

La surface Web es aquella parte de la Web accesible por los motores debúsqueda generales, cuyas páginas son estáticas y enlazadas con otras páginasestáticas [5].

Existen diversos estudios que dan una idea del tamaño y la importanciade la hidden Web [5, 11]. Un estudio realizado entre el 13 y el 30 de Marzo de2000 [5] reveló que:

1. Tamaño: La hidden Web es entre 400 y 550 veces mayor que la surface

1.1. ¿Qué es la hidden Web? 5

Crawling a través de formularios de búsqueda

Google está continuamente probando nuevas ideas para mejorar su cober-tura de la Web. Una de estas ideas es, cuando se encuentra un formulario deuna aplicación de la hidden Web que sea de interés, se intenta realizar algu-nas consultas para obtener la información resultante. Si las páginas resultantesson catalogadas como de interés, se indexan en el motor de búsqueda. De es-ta manera, Google puede indexar contenidos pertenecientes a la hidden Web[36].

Web.

2. Cantidad de aplicaciones: Existen más de 200.000 aplicaciones pertene-cientes a la hidden Web.

3. Calidad de información: El contenido de la hidden Web es muy específi-co y relevante.

4. Cantidad de información: Contiene 7.500 TB de información compara-dos con los 19 TB de la surface Web.

5. Contenido específico: Más de la mitad del contenido de la hidden Webse encuentra en bases de datos de un dominio temático específico.

6. Tráfico: Estas mismas aplicaciones reciben un 50 % más de tráfico men-sual que las de la surface Web.

7. Acceso público: El 95 % de la hidden Web es públicamente accesible (nosujeto a pagos o subscripciones).

Un artículo aparecido recientemente en Official Google Webmaster CentralBlog en abril de 2008 [36], afirma que Google está avanzando en su interés porla hidden Web y está comenzando a aplicar técnicas de crawling para accedere indexar los contenidos de interés pertenecientes a la hidden Web.

Un crawler (o Web crawler) es un programa o script automático que nave-ga por la Web de manera automática y metódica.

Los motores de búsqueda generales indexan la Web mediante técnicas decrawling [5]. Para que una página pueda ser descubierta e indexada debe ser


The Robots Exclusion Protocol

Es un protocolo para controlar el uso de crawlers. El protocolo consiste encrear un fichero de texto con nombre ’robots.txt´ donde se especifica la prohi-bición de acceso a ciertas URLs de una aplicación Web http://www.robotstxt.org/robotstxt.html.

Cualquier crawler debe tener en cuenta este protocolo para no ser consi-derado de riesgo.

una página estática y estar enlazada con otras páginas. Los crawlers van reco-rriendo la Web visitando todos los enlaces encontrados e indexando conteni-dos.

Los motores de búsqueda tienen otro mecanismo para indexar páginasademás del crawling. Permiten dar de alta URLs de forma manual o auto-mática, de manera que, si se desea que algún motor indexe alguna páginaconcreta, se debe registrar siguiendo este método. Un ejemplo es Google Ba-se (http://base.google.com/) donde se pueden dar de alta diferentes tipos deitems.

Sería muy interesante acceder a la hidden Web para extraer de manera au-tomática sus contenidos. Para poder llevar a cabo este acceso, es necesarioefectuar consultas a las aplicaciones Web, las cuales generan páginas diná-micas con la información de interés. Las únicas interfaces que proporcionanlas aplicaciones de la hidden Web son sus formularios de búsqueda, donde elusuario rellena los campos para acceder de manera explícita a la información.Los formularios de búsqueda están pensados para ser manipulados por usua-rios, es decir, no son procesables por un ordenador. Esto provoca que el accesoa dicha información de manera automática sea un reto de investigación.

Los motores de búsqueda generales no pueden acceder a la hidden Webporque no son capaces de rellenar los formularios de búsqueda. Los conteni-dos de este tipo de aplicaciones Web quedan ocultos a los motores generalesy debe de encontrarse dicha información por otras vías. Algunos motores debúsqueda como Google están avanzando en este campo, realizando consultasa formularios de aplicaciones de la hidden Web e indexando contenidos. Sinembargo, las páginas indexadas pueden quedar desfasadas tanto por los da-tos que incluyen como por cambios en los enlaces estáticos. Para apoyar esta

http://www.robotstxt.org/robotstxt.html

http://www.robotstxt.org/robotstxt.html

http://base.google.com/

1.2. Accediendo a la hidden Web 7

afirmación veremos un ejemplo.

Realizando en Google la consulta “dblp rafael corchuelo”, nos ofrece comoprimer enlace las publicaciones de Rafael Corchuelo que DBLP tiene alma-cenadas. Otro ejemplo consiste en consultar “blade runner book”, donde sepresenta el enlace del libro Blade Runner en Amazon. Estos dos ejemplos sondos claros accesos a la hidden Web desde un motor de búsqueda general.

En los ejemplos anteriores no se accede a la información rellenando el for-mulario de búsqueda de DBLP con Author: rafael corchuelo, o de Amazoncon Book Title: blade runner, sino que se accede a las páginas indexadas enel buscador. Estas páginas indexadas han podido ser descubiertas rellenandoformularios e indexando los resultados, o dadas de alta de manera manual oautomática. La información que almacena el motor de búsqueda puede que-dar desfasada, ya sea porque la páginas queden sin enlazar o los datos pierdanvigencia: las páginas web pueden cambiar de URL y perder el enlace o un libropuede dejar de comercializarse.

1.2. Accediendo a la hidden Web

Existen distintas formas de acceder a la hidden Web, principalmente la vi-sión crawling y la visión metasearch [1]. Cuando se accede a la hidden Webmediante crawling, se realizan consultas preestablecidas sobre los distintosformularios de búsqueda para acceder a la información e indexar las páginasresultantes. Algunas propuestas en este sentido son HiWE [45, 46], DeepBot[1] o el trabajo de Da Silva et al. [32].

Un ejemplo de acceso de tipo crawling es el siguiente: teniendo como con-sulta preestablecida Author: Philip K. Dick y Title: Blade Runner, el cra-wler posee una base de datos de enlaces Web. El crawler recorre cada enlacey, cuando encuentra un formulario, necesita identificar los campos que co-rresponden al autor y al título. Para identificar estos campos normalmente seutilizan técnicas heurísticas descubriendo el texto que designa a cada campo.Una vez descubiertos los campos, se rellenan con los valores de las consul-tas preestablecidas y se realiza un envío del formulario. En nuestro ejemplo,buscamos los libros de Philip K. Dick con título Blade Runner. La respuesta esanalizada e indexada en el sistema.

Para acceder a la hidden Web mediante metasearch, se combinan todos losformularios de búsqueda de un mismo dominio temático en un único formula-rio que el usuario se encarga de rellenar. Estos formularios unificados puedenser de Venta de libros, de DVDs o de música. Cuando el usuario termina de


rellenar el formulario unificado, se rellenan los formularios objetivo con losvalores previamente especificados. Los formularios objetivo son consultadosen tiempo real y se ofrece las respuestas de cada uno al usuario. Algunas pro-puestas de tipo metasearch son Metaquerier [12] o el trabajo de Meng et al.[23, 24].

1.3. IntegraWeb

IntegraWeb es un proyecto de investigación cuyos participantes son miem-bros de las universidades de Sevilla y Huelva. Posee dos fuentes de financia-ción, una del Ministerio de Educación y Ciencia y otra de la Junta de Andalu-cía. El investigador principal es Rafael Corchuelo. El objetivo del proyecto esidear e implementar un framework que ayude al desarrollo de soluciones deintegración de aplicaciones Web.

Una posible forma de llevar a cabo la integración de aplicaciones Web esproporcionar interfaces de programación expuestas mediante tecnología deServicios Web. Las interfaces de programación exponen parte o la totalidadde la funcionalidad de cada aplicación. En este caso, basta con transformarla consulta de usuario en el contexto de llamadas a Servicios Web adecuadosy procesar los resultados. Estos resultados son datos procesables automática-mente.

Emplear Servicios Web implica tener que desarrollar las interfaces de lasaplicaciones a integrar si no las llevaban incorporadas desde un principio.Desarrollar las interfaces conlleva un gasto debido a que es necesario hacerreingeniería de las aplicaciones en funcionamiento. La reingeniería puede serdemasiado costosa en aplicaciones cuya separación entre las capas de presen-tación y lógica de negocio es inexistente o poco clara. En aplicaciones Webexternas, dicha reingeniería es imposible porque no se proporciona acceso pú-blico a sus recursos.

Las aplicaciones cuya reingeniería es demasiado costosa o imposible derealizar son denominadas aplicaciones Web no desmantelables. Una solucióna la integración de aplicaciones Web no desmantelables es proporcionar un ac-ceso programático a las mismas, empleando la interfaz de usuario que ofrececada aplicación Web, es decir, el/los formulario/s de búsqueda de la aplica-ción.

Las aplicaciones Web no desmantelables son elementos de información ais-lados y se les conoce también como islas de datos Web. La principal caracte-rística de las islas de datos es que están orientadas al usuario, permitiendo

1.3. IntegraWeb 9

un fácil acceso e interacción mediante el uso de formularios de búsqueda. Laprincipal desventaja es que realizar una extracción automática de los datosque la componen es muy complejo.

El objetivo de la arquitectura de referencia IntegraWeb es la integraciónde islas de datos Web, recibiendo consultas de usuario en un lenguaje de altonivel (tipo SQL) y consultando las distintas islas. Para realizar consultas, seaccede a la información a través de los formularios de búsqueda, extrayendola información de interés, verificando dicha información y dando semántica.

Existen dos paradigmas fundamentales a la hora de acceder a la hiddenWeb: crawling y metasearch. Los objetivos que persigue IntegraWeb hace quesea mucho más cercano al paradigma de metasearch que al de crawler. Com-parte con los dos paradigmas una regla general: para integrar o extraer infor-mación de la hidden Web es necesario acceder a las aplicaciones a través delos formularios de búsqueda, al ser el único punto de entrada a la información.Aunque IntegraWeb esté más cercano al paradigma metasearch no es una so-lución de tipo metasearch, ya que no está ligado a ningún dominio temáticoconcreto.

IntegraWeb está divido en cuatro módulos: Information Retrieval, Extrac-tor, Verifier y Ontologiser. En la Figura §1.2 puede verse un esquema de laarquitectura de IntegraWeb. El flujo de información comienza cuando el usua-rio especifica una consulta expresada en un lenguaje de alto nivel, con losvalores especificados en la consulta se rellenan los formularios objetivo. Unavez rellenados los formularios, se realiza el envío de los mismos y se obtienenuna serie de páginas de resultados como respuesta. Cada página de respuestapuede ser una página de error o un listado con algún formato determinado.Para alcanzar las páginas de interés, hay que navegar por las páginas de resul-tados hasta encontrarlas. Todas estas tareas son responsabilidad del móduloInformation Retrieval.

Por cada página de interés encontrada, el módulo Extractor realiza una ex-tracción de la información que se encuentra en dicha página. Los extractoresde información pueden ser aplicados a páginas en lenguaje natural [54] o apáginas estructuradas y semiestructuradas [9]. El resultado es una serie de re-gistros de información que deben ser verificados para comprobar su validez,de esta tarea se encarga el módulo Verifier. La verificación de estos registros deinformación ayuda al mantenimiento y reparación de los extractores de infor-mación [30, 33, 37]. Por último, para aquellos registros de información correc-tos, el módulo Ontologiser se encarga de darles semántica. Todo IntegraWebestá respaldado por una base de conocimiento de los distintos dominios temá-ticos que sirve de apoyo al proceso.

10 Capítulo 1. IntroducciónVerifier Ontologiser

Knowledge Base

ExtractorInformation retrieval

OntologyDataset

SQLSQL

Figura 1.2: Esquema de la arquitectura de IntegraWeb.

En IntegraWeb se combinan los aspectos más relevantes del crawling ydel metasearch. En cuanto a los aspectos de crawling, es necesario rellenarformularios para acceder a la información y se realizan navegaciones por losenlaces de las páginas. En cuanto a los de metasearch, se reciben consultasde usuario y se consulta los formularios de aplicaciones pertenecientes a lahidden Web. Pero no sólo se dan estas características, sino que se combinancon otras características como la extracción de información, la verificación y laaplicación de semántica.

El objetivo de nuestra investigación está centrada en el módulo Informa-tion Retrieval.

1.4. Hipótesis y cuestiones de investigación

No existen soluciones que accedan a la hidden Web a partir de una con-sulta de alto nivel.

En nuestro escenario inicial, existen una serie de aplicaciones Web que con-sultan cada una su propia base de datos interna y, los datos que se ofrecen, son

1.4. Hipótesis y cuestiones de investigación 11

presentados de una manera semiestructurada. Gracias a esta presentación sepuede inferir el esquema presente en la base de datos oculta. Estas aplicacio-nes Web forman parte de la llamada hidden Web, algunos ejemplos de estetipo de aplicaciones en el contexto de Venta de libros son Amazon o Barnes &Noble.

La característica principal de las aplicaciones que forman parte de la hid-den Web es que tienen una interfaz de usuario avanzada. No estamos interesa-dos en formularios con un único campo a rellenar y que, mediante la consultacon palabras clave, ofrece la información que se quiere consultar. Nos centra-mos en aquellos formularios avanzados con más de un campo que permitenrefinar las búsquedas permitiendo, por ejemplo, buscar un libro por su fechade publicación y autor, o un DVD por el director de la película y el nombre delactor principal.

Las cuestiones de investigación que surgen de nuestra hipótesis son:

CI1 → ¿Es posible consultar uno o varios formularios de búsqueda ha-ciendo uso de lenguajes de alto nivel?

Esta primera cuestión es la base de toda nuestra investigación. Una vezanalizada parte de la bibliografía existente, la cuestión principal se des-dobla en 3 cuestiones que afectan a: cómo se modela un formulario debúsqueda, el estudio de la viabilidad de una consulta sobre un formula-rio y establecer planes de ejecución al realizar consultas complejas.

CI1.1 → Los actuales formularios de búsqueda están diseñados por/parausuarios, ¿se puede obtener un modelo computacional de los formula-rios de búsqueda?

Los formularios de búsqueda están pensados para la interacción con elusuario, es necesario establecer un modelo para hacer los formulariosprocesables automáticamente. Una característica deseable de este mode-lo es que pueda ser extraído de manera automática.

Este modelo será la base para resolver las cuestiones de investigaciónrestantes. El usuario puede enviar consultas de alto nivel que son tras-ladadas a los formularios de las diferentes aplicaciones Web. Si se desearealizar esta traslación con garantías, es necesario establecer un modelosuficientemente amplio que dé respuesta a cualquier necesidad de infor-mación.

CI1.2 → ¿Cómo se decide si una consulta de alto nivel es viable en elcontexto del esquema global de datos que forman las aplicaciones de lahidden Web?


Teniendo una consulta y una serie de formularios objetivo es necesarioestudiar, evitando un proceso de prueba-error, cómo decidir cuándo di-cha consulta es viable para acceder al esquema global de datos compues-to por las distintas aplicaciones Web integradas. No es una buena solu-ción ejecutar consultas para ver si son correctas o generan algún tipo defallo, es necesario algún mecanismo de comprobación de la viabilidad.Además, la ejecución de las consultas a veces es imposible, por ejemplo,si se consulta por la editorial de un libro y el formulario de búsquedaobjetivo no hace referencia a la misma.

Un ejemplo de viabilidad de consultas es: supongamos un formularioque permite consultar el precio de un libro ya sea menor de diez, entrediez y veinte y mayor de veinte euros. Se consulta los libros que tienenprecio igual a quince euros, ¿es esta consulta viable? En sentido estrictoes inviable porque no se da la opción de especificar un precio exacto.Sin embargo, se puede consultar los libros entre diez y veinte euros y,posteriormente, filtrar los resultados para obtener los libros con precioquince exacto.

Este problema está muy relacionado con el estudio de la viabilidad deuna consulta sobre una base de datos formada por la composición denumerosas vistas. Dada una consulta, se analiza sin ser ejecutada si conlas vistas existentes puede ser respondida o no.

CI1.3 → ¿Es posible dividir una consulta de alto nivel en varias subcon-sultas, derivar las subconsultas resultantes a los formularios objetivo ycombinar los resultados que ofrece cada formulario?

Se hace necesario el cómputo de un plan de ejecución para cada consultaviable ejecutada sobre el esquema global de datos. El usuario lanza unaconsulta sobre dicho esquema que está compuesto por las aplicacionesintegradas. La consulta objetivo se divide en varias subconsultas, queimplican sólo a condiciones aplicables a cada formulario de búsqueda, yse lanza cada subconsulta sobre cada uno de los formularios.

La idea básica para solucionar este problema es encontrar una correspon-dencia entre la consulta, expresada en lenguaje de alto nivel y especifi-cada por el usuario, y los distintos formularios de búsqueda implicadosen la propia consulta.

Como ejemplo de planes de ejecución supongamos dos formularios deVenta de libros. Los dos formularios permiten consultar el precio de unlibro mientras que, uno de los formularios permite consultar la editorialy el otro no. Suponiendo que se consulta la editorial y el precio de los li-bros se forman dos subconsultas: una de ellas, con precio y editorial, seráderivada al formulario que permite la consulta de los dos. La otra sub-consulta, únicamente con precio, será derivada al formulario restante,

1.4. Hipótesis y cuestiones de investigación 13

quedando la editorial como un filtro posterior sobre los datos ofrecidos(si es que es posible aplicar dicho filtrado).

Este problema también ocurre en las bases de datos formadas por unconjunto de vistas. En este caso, cuando se ejecuta una consulta y es via-ble, es necesario generar un plan de ejecución para determinar qué vistasse emplean para resolver la consulta propuesta. Este problema se conocecomo reescritura de consultas. La optimización de consultas sobre basesde datos usando vistas predefinidas también está muy relacionado.

CI2 → ¿Existen lenguajes de alto nivel en la actualidad?

El lenguaje de alto nivel más conocido es el SQL, sin embargo, está muyligado a las bases de datos relacionales. Hay que profundizar en el es-tudio de los lenguajes de alto nivel existentes para establecer cuál es elmás apropiado en el contexto de la integración de aplicaciones de la hid-den Web. Este lenguaje podría ser alguno de los usados para consultarla Web semántica como SPARQL.

CI3 → ¿Existen tecnologías en la actualidad para realizar el rellenado deformularios y la navegación por las aplicaciones Web?

El objetivo es rellenar formularios y navegar por páginas Web de mane-ra automática. Para llevar a cabo estas acciones, necesitamos proveernosde la tecnología necesaria, ¿permite la tecnología actual este tipo de au-tomatizaciones?

La mayoría de las herramientas estudiadas no tienen como objetivo elrellenado o la navegación en sí, sino que se engloban en una temáticamás genérica como es el Web testing. Estudiaremos las distintas herra-mientas comerciales que se encuentran en el mercado para decidir cuáles la que mejor se adapta a nuestra necesidades.

CI4 → Una vez obtenidos los resultados de una consulta sobre un for-mulario, ¿cómo se identifica si la página de respuesta es de error o unlistado de objetos? ¿Qué navegaciones hay que efectuar sobre el listadohasta obtener los objetos de interés?

Una vez relleno el formulario con los valores de la consulta del usuariose realiza un envío del mismo. Como respuesta se recibe una página quepuede ser una página de error o un listado de objetos. Una de las necesi-dades es la clasificación automática de páginas de resultados, sabiendosi una página de resultados es de error o un listado.

Cuando se recibe un listado, es necesario navegar por los registros hastaencontrar las páginas que contengan los datos de interés. Estas páginasserán las que se servirán a los extractores para realizar la extracción dela información.


Barnes & Noble

Amazon

Fnac

BooksExample

SELECT * FROM BARNES&NOBLE, AMAZON, FNAC, BOOKSEXAMPLEWHEREAuthor = ‘Philip K. Dick’ and Title = ‘Blade Runner’

Figura 1.3: Visión de la hidden Web como un esquema global de datos.

1.5. Objetivos

El objetivo de nuestra investigación es estudiar la integración de aplicacio-nes de la hidden Web no desmantelables. La idea básica es proporcionar unavisión unificada de todos los datos que contienen las aplicaciones Web de lasolución de integración. El usuario es capaz de lanzar consultas en lenguajede alto nivel para acceder a los datos, quedando ocultas las diferentes inter-faces de usuario. La Figura §1.3 ilustra nuestra idea básica. Una solución ala consulta propuesta en la Figura §1.3 puede verse en la Figura §1.4, dondelos formularios involucrados se han rellenado con el autor Philip K. Dick y eltítulo Blade Runner.

El objetivo de esta memoria es estudiar la literatura y soluciones existentesque pueden ser aplicadas para responder a las cuestiones de investigación. Enconcreto, por cada cuestión de investigación, existe un capítulo que describenuestro estudio de dicha cuestión. Queda fuera del ámbito de esta memoriadar respuesta a la pregunta CI1.2, CI1.3 y CI4 por cuestiones de planificación.Estas cuestiones son las correspondientes a la viabilidad de consultas, los pla-nes de ejecución y la navegación automática.

1.6. Estructura 15

Figura 1.4: Rellenado de formularios con una consulta de ejemplo.

1.6. Estructura

El documento está estructurado de la siguiente forma: en el capítulo §2 pre-sentamos la organización de nuestro estudio del estado del arte. El capítulo §3profundiza en el acceso a la hidden Web. El capítulo §4 presenta el estado delarte del modelado de formularios de búsqueda, con el objetivo de transformarun formulario en un modelo computacional automáticamente. Este capítuloresponde a la cuestión CI1.1.

El capítulo §5 trata de los diferentes lenguajes de consulta de alto nivelexistentes para la Web semántica, respondiendo a la cuestión CI2. El capítulo§6 presenta distintas herramientas comerciales de Web testing válidas para elrellenado de formularios y la navegación automática por páginas Web. Estecapítulo hace referencia a la cuestión de investigación CI3. Por último, en el


capítulo §7 presentamos las conclusiones que dan respuesta a las cuestionesde investigación analizadas en este documento.

Los anexos incluyen una implementación de un trabajo de Álvarez et al.para el cálculo de viabilidad de consultas SQL §A, el formulario de estudioque se emplea en toda la memoria §B.1, los distintos bancos de pruebas em-pleados por las propuestas estudiadas §B.2, algunos ejemplos de formulariosde la hidden Web §B.3 y el código fuente del formulario de ejemplo §B.4.

Parte II

Estado del arte

Capítulo 2

Introducción

I’ve got a more graceful solution to the memory problem. I’m disciplined and organized. I usehabit and routine to make my life possible.

Leonard Shelby, Memento, 2000

E n este capítulo presentamos un mapa mental con la organización deesta memoria y de todo nuestro trabajo de investigación. Además,

establecemos el protocolo que seguimos a la hora de revisar la bibliografíaexistente.


2.1. Introducción

Nuestra hipótesis ha planteado una serie de cuestiones de investigacióna las que debemos dar respuesta. Nuestro estudio del estado del arte se cen-trará en estudiar las diferentes propuestas existentes que dan solución a lascuestiones de investigación, dando una visión descriptiva de cada propuestay haciendo una comparativa de cada una de ellas con respecto a los problemasabordados.

Nuestro método de trabajo incluye tener organizados todos los trabajosque vamos analizando en un mapa mental. Esta representación nos sirve co-mo material de apoyo para nuestras reuniones, clasificar los trabajos para lo-calizarlos fácilmente y tener una imagen estática de nuestra investigación queclarifica nuestra visión de conjunto.

2.2. Organización del estudio del estado del arte

El estudio del estado del arte realizado está organizado en una estructurade mapa mental. Preferimos esta representación ya que nos es útil para tenerun esquema global que nos guía, nos sirve en las reuniones como material deapoyo básico y clarifica nuestra visión de la bibliografía estudiada.

El mapa mental se divide, por un lado, en todos los problemas encontradosa la hora de modelar formularios de búsqueda. Se muestran todos los proble-mas encontrados y los trabajos que solucionan parte o todo el problema endonde se agrupan. Por colores se distinguen los distintos autores para que tra-bajos del mismo autor se reconozcan visualmente. Por otro lado, se exponenotro tipo de problemas que son abordados en los trabajos pero que no afectandirectamente a nuestros temas de interés. Nos parece oportuno incluirlos paraque se distinga cuáles son nuestros temas de interés y qué temas quedan fuerade nuestra investigación.

Como se observa en la Figura §2.1, los trabajos han sido ordenados portemas. En Hidden Web tenemos los distintos informes que hemos encontradoque tratan sobre la hidden Web, definen qué es y describen sus principalescaracterísticas. Access to Hidden Web alberga los trabajos que acceden a lahidden Web, por un lado las propuestas tipo crawler y por otro las de tipo me-tasearch. En las propuestas de tipo metasearch están recogidos los distintosproblemas que son tratados en la bibliografía, como por ejemplo la localiza-ción de fuentes o el dominio temático al que pertenece el formulario.

2.2. Organización del estudio del estado del arte 21

State of the art

Hidden Web

Bergman01

ChangHLPZ04

MadhavanH08

Access to Hidden Web

Crawler

RaghavanG01

LiddleESY02

BergholzC03

LageSGL04

AlvarezRPCBC07

WuWLM06

Metasearch

MetaQuerierChangHZ04

ChangHZ05

Source locating

BarbosaF05

KabraLC05

Form domain

GravanoIS03

Kushmerick03

HeTC04

PengMHY04

LuHPMY06

AlvarezRPCBC07

Web interface merging

HeMYW03

HeC03

HeCH04

WuDY05

DragutYM06

DragutWSYM06

Query Translation

ChangG99

ChangG00

ChangG01

ZhangHC05

Feasibility

Views

FriedmanLM99

CalvaneseLL01

McBrienP03

XuE04

ManjunathSRKMRRM08

Query capabilities

YerneniLGU99

PanMMARV02

PetropoulosDP06

Answering queries

Halevy01

Execution plan

DeutschKP05

QuilitzL08

Form Model

Form field and label extraction

RaghavanG01

KaljuveeBGP01

ModicaGJ01

WangL03

LageSGL04

ZhangHC04

GalMJE05

HeMYW05

AlvarezRPCBC07

HeMLYW07

NguyenNF08

Mandatory field identification

ShuMHY07

Attribute identification and semantic matching

RahmB01

RaghavanG01

KaljuveeBGP01

ModicaGJ01

HeC03

Kushmerick03

HeMYW03

HeCH04

HeC04

WuYDM04

HeMYW04

LageSGL04

Noy04

GalMJE05

KalfoglouS05

DoanH05

ShvaikoE05

HeC06

WuDY06

AlvarezRPCBC07

Euzenat2007b

Advanced semantic information identification

Fields orderModicaGJ01

HeMLYW07

Attribute typeShuMHY07

Form field and label grouping

Logic relationships

Query capabilities extraction

ZhangHC04

ShuMHY07

Figura 2.1: Organización del estudio del estado del arte (mapa mental).


Respecto a los problemas tratados directamente en este documento estánel modelado de formularios de búsqueda en Form model correspondiente ala cuestión CI1.1, con todos los problemas asociados y los trabajos que danrespuesta a cada uno. Feasibility recoge las distintas propuestas sobre via-bilidad de consultas de alto nivel, vistas y planes de ejecución de consultas.Todas estas propuestas se corresponden con las cuestiones CI1.2 y CI1.3. Cree-mos que el problema de la viabilidad está muy relacionado con el problemade la traducción de consultas de un formulario a otro en el contexto de lassoluciones metasearch y la capacidad de consulta de formularios, de ahí queestén relacionados los problemas entre ellos.

2.3. Protocolo de revisión de la bibliografía

Para la revisión de la bibliografía existente establecemos un protocolo si-milar a los aplicados en las revisiones sistemáticas [29]. Nuestro protocolo derevisión incluye algunos de los elementos siguientes:

Las cuestiones de investigación a las que se dará respuesta con la revi-sión.

La estrategia que se usa para realizar la búsqueda de trabajos.

Los criterios de selección de trabajos, es decir, métricas para decidircuándo un trabajo será incluido en la revisión o no.

Con respecto a la estrategia de búsqueda de trabajos, nuestras principalesfuentes de información son Google Scholar y DBLP. Si descubrimos un autorrelevante o varios trabajos relevantes de un mismo autor o grupo de autores,analizamos todos los artículos indexados en DBLP. Además, para los trabajosrelevantes, buscamos los trabajos que citan al trabajo actual mediante el enlacecorrespondiente de Google Scholar.

Los criterios de selección de trabajos son dos, los criterios de los trabajosen sí y de los autores. En cuanto a los criterios de los trabajos, tenemos encuenta: el número de citas que indexa Google Scholar para dicho trabajo, si losautores han sido detectados como relevantes, la importancia de la conferenciao la calidad de la revista donde se publica el trabajo o la exactitud del temaque trata el trabajo. Los índices que empleamos para medir la importancia deuna conferencia son CORE, CSCR y CiteSeer entre otros. El índice que mide lacalidad de una revista es JCR. Un autor es considerado relevante dependiendode los trabajos que sean relevantes a su vez.

2.4. Conclusiones 23

2.4. Conclusiones

Al abordar la revisión bibliográfica con algunas ideas extraídas de las re-visiones sistemáticas y la estructuración visual de los trabajos como un mapamental, conseguimos que nuestro estudio del estado del arte sea exhaustivo ypresentado visualmente de forma amena y amigable al lector.

Capítulo 3

Acceso a la hidden Web

We’ll have to crawl.

Indiana Jones, Indiana Jones and the Temple of Doom, 1984

E n este capítulo profundizamos en las diferentes alternativas existen-tes para acceder a la hidden Web. Estudiamos a fondo los dos prin-

cipales paradigmas (crawling y metasearch) y repasamos las propuestas másrelevantes.

26 Capítulo 3. Acceso a la hidden Web

3.1. Introducción

Nuestro contexto de investigación gira en torno a la hidden Web y nues-tro objetivo es acceder a la misma, de forma programática y a partir de unaconsulta de alto nivel, motivados por la valía de la información que contie-ne. De esta forma, vemos necesario profundizar en las distintas técnicas parallevar a cabo el acceso a la hidden Web. Existen propuestas que acceden a lainformación contenida en la hidden Web.

Las propuestas recogidas en la bibliografía pertenecen a uno de los dosparadigmas principales en el acceso a la hidden Web: crawling o metasearch.El crawling consiste en visitar de manera metódica y automatizada toda laWeb, generando un índice de páginas encontradas para, posteriormente, po-der realizar consultas sobre las mismas. Cuando se trata de la hidden Web, uncrawler debe poder acceder a las páginas mediante consultas a los formulariosde búsqueda.

Los sistemas de tipo metasearch funcionan recibiendo una consulta deusuario, esta consulta es redirigida a un conjunto de aplicaciones Web. Losresultados obtenidos por cada aplicación son combinados, devolviendo unaúnica respuesta unificada. Estos sistemas ofrecen un formulario unificado pa-ra que el usuario haga sus consultas sobre el mismo y después son redirigidasa los formularios objetivo. La combinación de formularios [15, 20, 21, 24] es unpaso fundamental en las soluciones metasearch.

Otros problemas a los que se enfrentan las propuestas de tipo metasearchson el descubrimiento automático de fuentes de información. Es necesario en-contrar nuevas fuentes de manera automática [3, 26] para que puedan serincluidas en la solución y permitan ofrecer al usuario más variedad en susconsultas. El descubrimiento automático de fuentes necesita de clasificado-res temáticos de formularios, es decir, dado un formulario saber cuál es sudominio temático, por ejemplo, Venta de libros o Venta de billetes de avión[1, 22, 31, 35, 42]. La traducción de consultas [10, 57] consiste en realizar unatraducción desde un formulario relleno a otro sin rellenar. El usuario rellenael formulario unificado y, para poder llevar la consulta a los formularios obje-tivo, hay que realizar una traducción desde el formulario unificado al resto deformularios objetivo.

3.2. Características de crawling y metasearch 27

3.2. Características de crawling y metasearch

Una característica común a cualquier propuesta que acceda a la hiddenWeb es que, para poder extraer la información de las aplicaciones Web, es ne-cesario acceder a través del formulario de búsqueda. Como los formulariosestán pensados para la interacción con un usuario, el acceso a la hidden Webrequiere de la simulación de interacciones humanas sobre los formularios. Elreto de investigación consiste en llevar a cabo estas interacciones de maneraautomática sin ninguna intervención del usuario. Uno de los pasos fundamen-tales a la hora de afrontar este reto es transformar un formulario de búsqueda,diseñado por/para usuarios, en un modelo computacional procesable auto-máticamente.

Como ejemplo, algunos de los modelos encontrados en la bibliografía va-rían desde la ausencia del mismo hasta un modelo computacional complejo.Por un lado, en [34] se realiza un crawling sobre aplicaciones de la hidden Webrealizando envíos de los formularios tal y como se presentan al cargar la pá-gina en el navegador, es decir, con los valores de los campos por defecto. Estasolución no requiere de ningún modelo. Por otro lado, en [23] se obtiene unmodelo computacional capaz de contener los campos del formulario con sustipos de datos, las agrupaciones entre campos semánticamente relacionados olas relaciones lógicas que se establecen entre los campos a la hora de enviaruna consulta al servidor.

Existen dos diferencias fundamentales que distinguen las propuestas detipo crawling de las de tipo metasearch. La primera diferencia es si tiene encuenta la semántica de las aplicaciones a las que acceden. La segunda dife-rencia es la manera de acceder a la información, si se realiza en tiempo real osobre un repositorio creado tras la extracción de información.

Las técnicas de crawling toman información de varias aplicaciones Webpero realizando una búsqueda ciega, es decir, no interesa el dominio temáticode la aplicación, el único objetivo es visitar cuantas más aplicaciones mejorpara mejorar la cobertura del índice de páginas que se genera. Por otro lado,las propuestas de tipo metasearch también consultan varias aplicaciones Webpero interesándose por el dominio de cada aplicación, así, se crean interfacesde consulta para aplicaciones del mismo dominio temático.

Las técnicas de crawling son una solución de integración de tipo ETL (Ex-tract Transform and Load). ETL es una solución en la cual se ofrecen datos dediferentes aplicaciones como si se tratase de un gran y único esquema globalpero los datos son offline, es decir, no son datos vivos sino que se cargaron enun tiempo determinado y se trabaja con ellos.


Como ejemplo de ETL supongamos que existe una base de datos de auto-res de libros y se desea cargar estos datos a otra base de datos más completa,donde se recoge la información relativa a autores y libros. Las dos bases dedatos funcionan con tecnologías diferentes. El proceso consiste, primero, enextraer los autores de la base de datos fuente a un formato estándar (por ejem-plo, XML). El segundo paso es la transformación de los datos para adaptarlosal esquema de la base de datos objetivo, por ejemplo, el nombre y apellidosdel autor constituye un único campo en la base de datos fuente, mientras queen la base de datos objetivo está separado en dos. Por último, los datos soninsertados en la base de datos objetivo.

Las técnicas de metasearch son una solución de integración de tipo EII (En-terprise Information Integration). EII es la actividad de combinar informaciónde aplicaciones dispares, de manera que se consigue una nueva y única vistade la información [19]. Sobre la vista global de datos que se ofrece, se propor-ciona además una API encargada de recibir consultas de usuario y ejecutarlassobre los datos. Para poder ejecutar las consultas sobre los datos, hay que te-ner en cuenta que están distribuidos por diferentes aplicaciones, por tanto,será necesario una separación lógica de las consultas, ejecutar cada parte porseparado sobre las aplicaciones apropiadas y combinar los resultados obteni-dos para poder devolverlos al usuario. La diferencia principal con respecto aETL es que la consulta de los datos se realiza de forma online.

3.3. Propuestas de tipo crawling

A continuación, presentamos las propuestas de tipo crawling que, en nues-tra opinión, son las más relevantes de las encontradas en la bibliografía. Seofrece al lector información relativa a los autores de las propuestas. Esta infor-mación incluye sus actuales ocupaciones, el número aproximado de citas queposeen y otra información de interés.

3.3.1. HiWE

Raghavan y Garcia-Molina [46] proponen un crawler llamado HiWE (Hid-den Web Exposer). Este crawler viene acompañado de una técnica de extrac-ción de información de páginas Web llamada LITE (Layout-based InformationExtraction Technique) basada en la disposición visual de los elementos de unapágina Web.

Según los autores, un crawler que recorra la hidden Web debe simular las

3.3. Propuestas de tipo crawling 29

Hector Garcia-Molina

Desarrolla su trabajo para la Universidad de Stanford, California. Fuemiembro del President’s Information Technology Advisory Committee (PI-TAC) desde 1997 a 2001. Forma parte del Comité Técnico Consultivo en Do-CoMo Labs USA, Yahoo Search & Marketplace. Sus intereses en investigacióngiran en torno a sistemas distribuidos, bibliotecas digitales y sistemas de basesde datos.

Los trabajos de Garcia-Molina indexados en Google Scholar reciben cente-nares de citas. En concreto, [46] posee más de 300 citas.

Figura 3.1: Interacción de un usuario con un formulario de búsqueda.

interacciones que un usuario realiza para definir una consulta sobre un for-mulario de búsqueda. Una interacción de un usuario puede verse en la Figura§3.1 [46], comparada con la interacción de un crawler de la Figura §3.2 [46].En una interacción de usuario, se presenta el formulario de búsqueda de unaaplicación Web. El usuario rellena el formulario y realiza un envío del mismo,la aplicación lo procesa y envía una respuesta. Esta respuesta es procesadapor el usuario de alguna forma, por ejemplo, visitando los distintos enlacespresentados.

El flujo de trabajo que adoptan este tipo de crawlers es el siguiente: cuan-


Figura 3.2: Interacción de un crawler con un formulario de búsqueda.

do se recibe un formulario, el crawler construye una representación interna dedicho formulario para poder trabajar con él. Cada crawler tiene asociado unrepositorio que contiene toda la información necesaria para poder formularconsultas relevantes para una tarea específica. El formato, estructura y organi-zación del repositorio depende de la implementación del crawler.

Tomando como entrada la representación interna del formulario y el repo-sitorio se establece una correspondencia entre ambos. Esta correspondencia sehace efectiva mediante la creación de una serie de asignaciones donde a cadacampo del formulario se le asigna un valor. Esta asignación no es única, sinoque puede haber más de una, y el crawler toma cada una de ellas para rellenary enviar el formulario de búsqueda.

La respuesta de la aplicación es procesada y almacenada para su accesoen un repositorio objetivo, mientras que esta información también sirve paramejorar el proceso de establecer asignaciones.

A partir del flujo de trabajo se construye un prototipo llamado HiWE. Laidea básica consiste en extraer una etiqueta que designe a cada campo de unformulario. El repositorio específico está compuesto por una serie de parescampo-valor. El algoritmo de correspondencia intenta obtener una serie deasignaciones de valores entre las etiquetas de los campos del formulario y loscampos del repositorio.

Un ejemplo de repositorio es, para el campo ‘Title’ que hace referencia altítulo de un libro, los valores asociados son ‘Blade Runner’, ‘Ubik’, .... A este


Alberto Pan y Manuel Álvarez

Alberto Pan es profesor de investigación (programa Ramón y Cajal) en laUniversidad de A Coruña. Actualmente, es director técnico de Denodo Tech-nologies. Manuel Álvarez es profesor asociado en la Universidad de A Coruñay actualmente trabaja en Denodo Technologies, sus intereses en investigaciónson: integración de información, problemas de integración de información,mediadores, wrappers en sistemas mediadores, optimización basada en capa-cidad en mediadores, Web semántica y hidden Web.

repositorio se le denomina tabla LVS (Label Value Set). En HiWE se usa con-juntos difusos para los valores del repositorio. Para cada uno de los valoresexiste una función que asigna pesos a cada uno, de esta manera, se puedeevaluar si una asignación es válida o no a partir de un umbral.

Para poder desarrollar toda la funcionalidad de HiWE se necesita un ex-tractor de información para ser usado en formularios de búsqueda y páginasde respuesta. Para llevar a cabo esta extracción, se usa una nueva técnica lla-mada LITE en donde se emplea, además de la información textual, la disposi-ción visual de la página.

LITE se basa en la observación de que la disposición visual de los elemen-tos en un página ofrece información semántica muy significativa. Por ejemplo,un texto que está cercano a un campo en un formulario probablemente sea sudescripción semántica. Aplicando una serie de heurísticas, como la disposi-ción visual cercana de los elementos, es capaz de extraer la representacióninterna de un formulario y la información de las páginas de resultados.

3.3.2. DeepBot

DeepBot es una propuesta de Álvarez et al. [1] y consiste en un prototipode crawler para acceder a la hidden Web. Recibe como entrada un conjunto dedefiniciones de dominio, cada una describiendo tareas específicas de recolec-ción de datos, y automáticamente identifica y aprende a ejecutar consultas enlos formularios relevantes.

En este trabajo se identifican los principales problemas que tienen los cra-


wlers que acceden a la hidden Web. Estos problemas pueden dividirse en dos:acceso desde el lado de la aplicación y del cliente. En los accesos desde el ladode la aplicación, para poder acceder a las bases de datos de la hidden Web esnecesario rellenar los formularios que ofrecen la información, por tanto, hayque aprender a ejecutar consultas sobre dichos formularios. En los accesosdesde el lado cliente, muchas aplicaciones Web emplean lenguajes de script ymecanismos de sesión cuando son accedidas para ser consultadas. A la horade implementar un crawler que acceda a la hidden Web habrá que hacer frentea estos problemas.

DeepBot hace frente a dichos problemas aportando al acceso desde el ladode la aplicación una serie de definiciones de dominio, describiendo tareas es-pecíficas de recolección de datos. Se detecta automáticamente los formulariosrelevantes a cada tarea en cuestión y se ejecuta una serie de consultas predefi-nidas sobre los formularios. DeepBot necesita como entrada estas definicionesde dominio. En cuanto al acceso desde el lado del cliente, DeepBot se basaen una serie de mini-navegadores capaces de hacer frente a las complejidadesanteriormente mencionadas.

DeepBot basa su funcionamiento (como muchos crawlers) en una listacompartida de rutas que apuntan a documentos. Dichos documentos son usa-dos por una serie de procesos concurrentes capaces de acceder a la hiddenWeb. Algunas diferencias de DeepBot con otros crawlers es que, además dealmacenar como ruta la URL, se almacena información referente a la sesión.El uso de mini-navegadores es algo novedoso, así como, por cada documen-to recibido, además de navegar por los enlaces que posee para aumentar elnúmero de rutas, si contiene un formulario HTML se estudia su relevanciausando las definiciones de dominio. En el caso de que un formulario sea rele-vante, se aprenderá a rellenarlo y se ejecutarán consultas predefinidas sobre élpara acceder a nuevos documentos y continuar el proceso de crawling.

3.3.3. Propuesta de Da Silva et al.

La propuesta de Da Silva et al. [32] describe un método para generar agen-tes de manera automática que sirvan para recolectar páginas de la hiddenWeb. Para ello, se sirve de un repositorio de datos para identificar los con-tenidos de las páginas. Se usa una serie de patrones de navegación que seencuentran en la mayoría de aplicaciones Web para identificar caminos de na-vegación a seguir. En la Figura §3.3 [32] se pueden ver los pasos a seguir en laconstrucción de un agente.

Un agente recibe la página principal de una aplicación Web y navega hasta


Altigran Soares da Silva

Es profesor adjunto en la Universidad Federal del Amazonas. Desde 2005es miembro de la dirección de Sociedade Brasileira de Computação (SBC).También es miembro de Brazilian Computer Society y de ACM. Sus interesesen investigación se centran en las bases de datos, recuperación de informacióny sistemas para la World-Wide Web.

Figura 3.3: Pasos para construir un agente que acceda a la hidden Web.

el formulario de búsqueda avanzada seleccionando el enlace correspondien-te. El formulario de búsqueda avanzada permite a los usuarios especificar susnecesidades de una manera mucho más expresiva que los formularios mássimples. Con el formulario de búsqueda avanzada, se rellenan los campos ne-cesarios y se realiza un envío del mismo. Tras estos pasos, se muestra unapágina de resultados. No toda la información disponible se encuentra en laprimera página, habrá que ir navegando por la misma para ir obteniendo to-da la información.

Un patrón de navegación marca el esqueleto de una posible navegaciónsobre una aplicación Web y que se repite en muchas otras aplicaciones. Dichoesqueleto se hace efectivo en una página Web llevando a cabo acciones concre-tas. Los autores restringen los patrones de navegación a dos, que son los máspopulares entre los diseñadores de aplicaciones Web.


El primero consiste en que, comenzando por la página de inicio, se llega alformulario de búsqueda avanzada mediante un enlace, se rellena y se realizael envío dicho formulario. Por último, se ofrecen las páginas de datos entre lasque hay que navegar a través de enlaces.

El otro patrón de navegación es el que, partiendo de la página principal,se llega al formulario de búsqueda avanzada a través de un enlace. Una vezrelleno el formulario, se envía al servidor y la página de resultados contieneuna serie de filtros que permiten refinar la búsqueda. Para obtener toda lainformación, habrá que navegar entre las distintas páginas que se ofrezcan.

Este último patrón de navegación se encuentra en muchos sistemas perotoma espacial relevancia en los Faceted Systems [13]. En este tipo de sistemas,se muestra al usuario una serie de clasificaciones para que el usuario pueda irrefinando la búsqueda hasta encontrar lo que desea. Un ejemplo de esto seríala Web de Faceted DBLP (http://dblp.l3s.de/).

Volviendo a la generación automática de agentes, el método consta de trespasos: encontrar los formularios de búsqueda, aprender a rellenarlos, e iden-tificar y buscar en las páginas de resultados.

Partiendo de un directorio Web que contiene diversas URLs, se recorre ca-da página buscando formularios que devuelvan páginas con la informaciónalmacenada en la aplicación Web. Para ello, se emplea una serie de heurís-ticas simples que consisten en contar los elementos del formulario, si dichoselementos no suman más de un umbral, se descarta el formulario. Además,si contiene algún elemento tipo contraseña (password de HTML), tampoco setiene en consideración el formulario.

Los formularios restantes del paso anterior se rellenan encontrando unacorrespondencia entre las cadenas de texto de los campos que lo componen,y las entradas de un repositorio de datos que se usa como referencia, esta co-rrespondencia se lleva a cabo mediante comparación de cadenas de texto. Paraconseguir dicha correspondencia, se parte de dos observaciones prácticas: losdiseñadores Web evitan usar navegaciones complejas y los formularios suelenparecerse mucho entre ellos.

Una vez establecidas las correspondencias, cada entrada del repositorio tie-ne asociado un valor, se rellenan los formularios con estos valores y, aplicandolos patrones de navegación, el agente es capaz de navegar por las páginas dedatos.

http://dblp.l3s.de/

3.4. Propuestas de tipo metasearch 35

3.3.4. Otras

En [34] aparece una propuesta cuyo objetivo es extraer toda la informaciónque aparece tras un formulario de búsqueda en la Web. Para ello, se sigue unproceso que incluye: ejecutar la consulta por defecto, analizar si la consultapor defecto devuelve resultados útiles y consultar el formulario de maneraexhaustiva hasta llegar a un cierto límite.

Los valores por defecto son aquellos que tenía la página inicialmente, esdecir, equivale a realizar un envío con el formulario tal y como se presenta porpantalla cuando se pide la página al navegador. De esta manera, si el formu-lario devuelve resultados, se consulta la aplicación Web exhaustivamente y,haciendo uso de técnicas de comparación de documentos, se analiza si se haalcanzado el límite de búsqueda deseado.

3.4. Propuestas de tipo metasearch

A continuación, presentamos las propuestas de tipo metasearch que desdenuestro punto de vista son más relevantes. Además, se ofrece al lector infor-mación relevante sobre los autores de dichas propuestas como ya hemos vistoen el caso de las propuestas tipo crawling.

3.4.1. Metaquerier

Metaquerier [12] es una propuesta de Chang et al. desarrollada en la Uni-versidad de Illinois en Urbana-Champaign (UIUC). Metaquerier tiene comoobjetivos principales explorar (encontrar) e integrar (consultar) bases de da-tos en la hidden Web. Como resultado de esta investigación se ha creadouna aplicación que ayuda al usuario a encontrar casas de alquiler en variasciudades de EEUU, como por ejemplo San Francisco, Chicago o Nueva York(http://apartments.cazoodle.com/).

A la hora de encontrar y consultar las aplicaciones en la Web los usuariospueden tener varios problemas, como por ejemplo no saber qué dirección con-sultar para encontrar alquileres de piso. Para ayudar a los usuarios a encontraraplicaciones para sus consultas, Metaquerier hace que la hidden Web sea ac-cesible de manera sistemática. Además, también tiene como objetivo permitirque la hidden Web sea uniformemente usable: ayuda a los usuarios a consul-tar las aplicaciones Web online. En la Figura §3.4 [12] se muestra un esquema

http://apartments.cazoodle.com/


Kevin Chen-Chuan Chang y Bin He

Kevin Chen-Chuan Chang es profesor asociado en la UIUC y participa enCazoodle Inc., su interés en investigación se centra en integración de informa-ción en la Web y recuperación de información. Bin He trabaja como investi-gador en IBM Almaden Research Center y su interés en investigación gira entorno a bases de datos.

Los trabajos de Chang y He indexados en Google Scholar cuentan concientos de citas.

Figura 3.4: Arquitectura de Metaquerier.

de la arquitectura de Metaquerier.

Como la Web posee una gran cantidad de aplicaciones de la hidden Web, latarea de integración debe realizarse a gran escala. Para ello, Metaquerier debeafrontar dos requisitos fundamentales: el descubrimiento dinámico y la inte-

3.4. Propuestas de tipo metasearch 37

gración al vuelo. En cuanto al descubrimiento dinámico, las fuentes de datoscambian a lo largo del tiempo y deben ser descubiertas de manera dinámicapara su integración. En Metaquerier no hay fuentes de datos establecidas apriori. En cuanto a la integración al vuelo, las consultas que se realizan sobrelas fuentes son ad-hoc, Metaquerier debe ejercer de mediador entre las consul-tas y las fuentes de datos de una manera dinámica (al vuelo). En Metaquerierno existe conocimiento configurado a priori por cada fuente de datos.

El principal reto al afrontar una integración a gran escala es realizar losdescubrimientos semánticos al vuelo. Algunos ejemplos de estas semánticasson cómo caracterizar y consultar una fuente de datos o cómo mediar entrelas consultas a varias fuentes. Para escenarios de integración pequeños y está-ticos, la automatización de los descubrimientos semánticos es una característi-ca opcional, para ayudar al usuario a configurar manualmente la semántica delas fuentes. Sin embargo, para escenarios de integración de gran envergaduradicha automatización es fundamental.

El diseño de Metaquerier consiste en un back-end para el descubrimientode semántica y un front-end para la ejecución de consultas. Metaquerier re-corre las fuentes de datos descubiertas y, por cada formulario de búsqueda,extrae su capacidad de consulta. Además, la integración está enfocada sobrefuentes de la hidden Web del mismo dominio, por tanto, es necesario desa-rrollar un agrupamiento de formularios de dominios concretos (por ejemplo,Libros, Vuelos, ...). Por último, para cada dominio, construye un formulariounificado y traduce las consultas del usuario desde el formulario unificadohasta los distintos formularios de las fuentes, encontrando las distintas aso-ciaciones semánticas entre campos.

El back-end analiza la semántica de las fuentes descubiertas, recolectafuentes de la hidden Web de manera automática (subsistema Database Cra-wler o DC [11]), extrae la capacidad de consulta de cada fuente (Interface Ex-traction, IE [56]), agrupa formularios en dominios (Source Clustering, SC [22])y descubre las asociaciones semánticas (Schema Matching, SM [20, 21]).

En el front-end se proporciona al usuario una jerarquía de categorías cons-truida automáticamente por el subsistema SC. Para cada categoría, el subsis-tema SM genera un formulario unificado. Un usuario elige primero un do-minio de interés (Libros, por ejemplo) y después realiza una consulta sobreel formulario unificado de dicho dominio. El front-end selecciona las fuentesapropiadas para responder a la consulta (Source Selection, SS). Con las fuen-tes seleccionadas, el front-end traduce la consulta del usuario a cada una delos formularios (Query Translation, QT [57]) y combina los resultados de laconsulta para devolverlos al usuario (Result Compilation, RC).


Weiyi Meng y Clement Yu

Weiyi Meng es profesor de la Universidad de Illinois en Chicago y susintereses en investigación son la recuperación de información en la Web, losmetabuscadores, integración de bases de datos Web y el procesamiento deconsultas y optimización. Clement Yu es profesor de la Universidad de Illinoisen Chicago y sus intereses son gestión de bases de datos y recuperación deinformación.

Los trabajos de Meng y Yu indexados en Google Scholar reciben cientos decitas.

3.4.2. Propuesta de Meng et al.

No existe ningún trabajo de Meng et al. que presente una solución comple-ta de tipo metasearch. Su trabajo se centra en las técnicas de tipo metasearchcon dos sistemas: WISE-Integrator [24] y WISE-iExtractor [23], desarrolladosambos en la Universidad de Illinois en Chicago.

WISE-Integrator se emplea para integrar varios formularios de búsquedaformando un único formulario unificado. Para desarrollar este formulario uni-ficado, se extraen los campos del formulario que hacen referencia a un mismoconcepto. Una vez extraídos estos campos, mediante el descubrimiento de co-rrespondencias semánticas, se calculan los campos globales de todos los for-mularios pertenecientes a un mismo dominio temático.

Con todos los campos globales calculados, se genera el formulario unifica-do que se presentará al usuario para que formule las consultas que necesite.En este caso, hay que decidir la posición del atributo dentro de la interfaz.Dependiendo de la importancia de cada atributo, se situará más arriba cuantomás ‘importante’ sea. Cuando se integran formularios con un gran número decampos, el formulario resultante puede no ser usable, por tanto, hay que selec-cionar los campos a incluir. Esta selección se realiza estableciendo un límite enla posición, pasado ese límite los campos restantes se eliminan del formulariounificado.

WISE-iExtractor propone un modelo para expresar formularios de búsque-da complejos y un método para, a partir de un formulario, realizar una extrac-ción automática de dicho modelo incluyendo: la extracción de etiquetas de


campos, identificación de agrupaciones de campos y etiquetas, identificaciónde tipos complejos, etc.

3.5. Conclusiones

Existen gran variedad de soluciones para acceder a la hidden Web. Motiva-dos por la valía de la información que almacena, estudiaremos más a fondo lasprincipales propuestas para analizar cómo resuelven los distintos problemasque también pueden afectar a nuestra investigación.

Algunas propuestas incluyen la extracción de información en su solución.Nosotros consideramos la extracción de información como un módulo inde-pendiente (ver descripción de IntegraWeb §1.3), ya que existen numerosaspropuestas de extractores de información cada una con sus ventajas e incon-venientes. Por tanto, el estudio de extractores de información no es nuestroobjetivo.

Capítulo 4

Modelado de formularios debúsqueda

Now they got the whole country sectioned off, you can’t make a move without a form.

Harry Tuttle, Brazil, 1985

E n este capítulo tratamos el modelado automático de formularios debúsqueda y los problemas asociados a este modelado. Analizamos la

bibliografía existente al respecto presentando las propuestas más relevantes yconcluimos con un framework de comparación de estas propuestas.

42 Capítulo 4. Modelado de formularios de búsqueda

4.1. Introducción

La extracción del modelo de un formulario de búsqueda es necesario pa-ra lograr la integración de diferentes aplicaciones de la hidden Web [23, 56].El modelo, además de otras funciones, ayuda a responder a la pregunta dequé consultas se pueden realizar sobre un formulario de búsqueda, es decir,cuáles son las distintas formas de consulta que ofrece. En general, el modelosirve de punto de partida para el tratamiento computacional de formulariosde búsqueda.

Existen varios problemas diferenciados en la extracción automática de unmodelo de un formulario. No todos los modelos encontrados en la bibliografíaresuelven todos los problemas encontrados. Una vez solventados los proble-mas, se obtiene un modelo computacional de un formulario de búsqueda: he-mos pasado de tener un formulario de búsqueda pensado para la interaccióncon un usuario, sin ninguna semántica computacional, a un modelo compu-tacional procesable automáticamente.

La extracción del modelo se lleva a cabo de forma automática [1, 23, 46, 56].Esta extracción automática no es una tarea trivial. Cada formulario de búsque-da es creado de manera autónoma y no existe ninguna guía global que sirvade referencia. El propio código HTML no proporciona ninguna semántica querelacione los campos del formulario y las etiquetas que acompañan a dichoscampos. Tampoco proporciona información de qué campos están semántica-mente relacionados dentro del formulario de búsqueda.

Las diferentes propuestas encontradas en la bibliografía aportan solucio-nes muy dispares en la extracción del modelo. Algunas soluciones extraen unmodelo simple que recoge los campos del formulario, se limitan a realizar unenvío del mismo con los campos rellenos de manera automática y no añadenninguna semántica. Otras propuestas poseen modelos más o menos completosque se extraen de manera automática, manual o una mezcla de ambas.

En el apartado §B.1 estudiamos un formulario de ejemplo y establecemosuna serie de definiciones que formarán el lenguaje común de toda nuestrainvestigación. Siempre que podamos hablar en los mismos términos, serán re-feridos a las definiciones expuestas en dicho apartado, cuando no sea posibleserá indicado explícitamente. Todos los ejemplos aclaratorios que se especifi-can son referidos al formulario del ejemplo comentado.

4.2. Problemas derivados del modelado 43

4.2. Problemas derivados del modelado

A continuación se detallan los distintos problemas encontrados a la horade modelar formularios de búsqueda. No todas las propuestas encontradas re-suelven todos los problemas, hay algunos trabajos que únicamente se centranen algún problema concreto.

Las diferentes propuestas estudiadas tienen dos estrategias a la hora demodelar: utilizar sólo la información presente en el lado cliente o, por el con-trario, usar tanto la información del cliente como del lado de la aplicación.La información del lado cliente es la información correspondiente a la partedel cliente en el esquema típico de aplicaciones Cliente - Servidor. Esta infor-mación se refleja en las aplicaciones Web en la información enviada desde laaplicación al navegador, es decir, el código fuente HTML, códigos de script oaplicaciones para ejecutar en cliente.

Los trabajos que tienen en cuenta tanto el lado cliente como el de la apli-cación, se sirven por un lado del propio formulario de búsqueda y, además,se apoyan en el envío de consultas sobre dicho formulario de búsqueda y elposterior análisis de los datos devueltos por la aplicación [52].

Los trabajos que sólo tienen en cuenta el lado cliente [1, 23, 56], realizanla extracción automática del modelo de un formulario de búsqueda utilizandocomo partida sólo el propio formulario. Trabajar únicamente con los datos vis-tos desde la perspectiva del cliente no impide que muchas propuestas trabajencon repositorios de información de respaldo, ontologías, técnicas heurísticas,gramáticas, etc.

A continuación se estudian en detalle los problemas derivados del mode-lado, a saber:

Extracción de etiquetas de los campos del formulario: Cada campo deun formulario suele estar acompañado de un texto que lo identifica se-mánticamente.

Identificación de campos obligatorios: Algunos formularios de búsque-da poseen una serie de campos obligatorios. Estos campos provocanerrores si no se rellenan al ser enviado el formulario a la aplicación.

Descubrimiento de atributos: Un campo o un conjunto de campos de unformulario pueden representar un concepto del dominio. Por ejemplo,dos campos con una lista de años cada uno pueden agruparse para con-sultar el año de publicación de un libro.


Establecimiento de correspondencias semánticas: Cuando se consideranvarios formularios de búsqueda, es necesario establecer corresponden-cias semánticas entre los distintos campos. Por ejemplo, si en un formu-lario el autor de un libro se consulta mediante un único campo de tipocaja de texto, y en otro formulario se consulta con dos cajas de texto, unapara el nombre y otra para los apellidos, se establecerá una correspon-dencia entre las dos cajas de texto de un formulario y la caja de texto delotro.

Identificación de información semántica avanzada: Esta información in-cluye detectar el orden de rellenado de los campos al realizar una con-sulta, si los atributos afectan al dominio o a la manera que se presenta lainformación o la agrupación de etiquetas y campos, entre otras.

Relaciones lógicas: Cuando se consulta un formulario de búsqueda, losatributos se combinan formando una condición lógica que es la que seenvía a la base de datos de la aplicación Web. Este problema consiste enla identificación automática de estas relaciones.

Extracción de la capacidad de consulta: La capacidad de consulta de unformulario indica las diferentes formas en que puede ser consultado.

4.2.1. Extraer etiquetas de campos

Todo formulario de búsqueda posee una serie de campos que el usuariotiene (obligatorio) o puede (opcional) rellenar. Para que un usuario que deseerellenar un formulario sepa a qué corresponde cada campo, en general, se sue-le proporcionar una información semántica consistente en una etiqueta textualque acompaña a cada campo. Leyendo una etiqueta, se puede saber a qué estáhaciendo referencia dicho campo. Existen ciertas convenciones en el desarro-llo de formularios de búsqueda a la hora de etiquetar campos [1, 23, 32, 46, 56].Un ejemplo de estas convenciones puede ser: una etiqueta de un campo está ala izquierda o encima del mismo.

Las diferentes propuestas estudiadas suelen hacer uso de este tipo de con-venciones para extraer las etiquetas asociadas a campos de un formulario. Unejemplo de etiqueta es Title, que acompaña a la caja de texto que está inme-diatamente debajo de la propia etiqueta, como se puede observar en la Figura§B.1. Sin embargo, Hardcover hace referencia al checkbox que está inmedia-tamente a su izquierda, aquí no se cumple el caso general de que la etiquetadebe estar a la izquierda o encima del campo.


La extracción automática de etiquetas puede realizarse de manera textual,analizando el código fuente HTML para descubrir dónde se encuentra cadaetiqueta [23, 32]. O analizar sintácticamente el árbol que forma el código fuen-te, o el propio árbol DOM [46]. También pueden usarse técnicas visuales par-tiendo de las posiciones relativas de los campos y etiquetas dentro del formu-lario [1, 56].

4.2.2. Identificar campos obligatorios

Los campos obligatorios de un formulario de búsqueda son aquellos quedeben ser rellenados para poder realizar un envío del mismo a la aplicaciónWeb. Si dichos campos no están rellenos al realizarse el envío del formulario,se genera un mensaje o página de error. El mensaje de error puede consistiren una marca visual sobre los campos que faltan por rellenar, una ventanaindicando de manera textual los campos que faltan, un error en la página re-sultante al enviar el formulario u otras posibilidades.

La identificación de estos campos es una tarea fundamental a la hora derealizar consultas. Si los campos obligatorios no están correctamente rellenos,no se podrá realizar consultas sobre el formulario de búsqueda y, por tanto, nose podrá obtener la información existente. Un ejemplo de campo obligatorio esLast Name en la Figura §B.1, en este caso puede ser visualmente identificadoal estar marcado con un asterisco, sin embargo, no siempre esta identificaciónvisual es posible.

Al no ser posible la identificación visual comentada, los campos obligato-rios tienen que identificarse mediante envíos de formularios a la aplicación yanalizando las respuestas [52].

Los campos obligatorios también afectan a la hora de estudiar si una con-sulta de alto nivel sobre un formulario de búsqueda es viable o no. Por ejem-plo, si se realiza una consulta sobre el formulario de la Figura §B.1 y no seespecifica el apellido del autor en la misma, es evidente que dicha consulta noserá viable sobre el formulario del ejemplo al no tener informado este campoobligatorio.

4.2.3. Descubrimiento de atributos

Una vez extraídas las etiquetas de los campos, el modelo puede enriquecer-se descubriendo qué campos del formulario forman los atributos. Un atributo


es un conjunto de campos y etiquetas que están relacionados y que represen-tan a un concepto del dominio o a cómo son mostrados los datos (ver apartado§B.1 para más detalles).

El descubrimiento de atributos varía entre la estrategia más simple: uncampo es un concepto, u otras opciones más complejas que pasan por el agru-pamiento de campos [23, 52]. Por ejemplo, en el formulario de la Figura §B.1,podemos interpretar que los campos after y before son dos conceptos. Otraposible interpretación es que juntos forman un rango interpretado como elconcepto Publication Year.

4.2.4. Establecimiento de correspondencias semánticas

Al ser extraídos los atributos es necesario darles semántica de alguna ma-nera. Es posible dar semántica a cada atributo obteniendo información a travésde su etiqueta, su posición dentro del formulario, otros campos o etiquetas quelo acompañen, etc. La idea es asignar una correspondencia entre un atributo yun concepto global u otros atributos de otros formularios.

Este problema tiene una amplia literatura a sus espaldas. El problema delas correspondencias semánticas viene de las bases de datos y continua conla Web semántica al extenderse el problema a las ontologías. Existen variossurveys respecto a este tema. Rahm et al. estudian en [47] las propuestas quehacen referencia a la integración de esquemas de bases de datos o el procesadode consultas semánticas (tipo SQL). Se establece una taxonomía donde se clasi-fican las distintas propuestas. Otro survey de las técnicas empleadas en basesde datos es [14] de Halevy et al., además de tratar las correspondencias se-mánticas, se estudia las correspondencias de datos (detección de duplicados) yotros problemas asociados (razonamiento con correspondencias, verificacióny reparación de correspondencias y la reconciliación de datos inconsistentes).

En la Web semántica el problema de correspondencias semánticas ocurrecon las ontologías. Las aplicaciones Web necesitan acceder a múltiples onto-logías distribuidas por la Web, por tanto, es necesario un mecanismo para es-tablecer este tipo de correspondencias [27]. Otro survey que trata el tema decorrespondencias semánticas con ontologías es [40].

Por último, existe otro survey que trata las correspondencias de esquemasde bases de datos y ontologías en conjunto [53]. De los mismos autores queel survey anterior es el libro [16], que posee página Web pública (http://www.ontologymatching.org/).

Las propuestas estudiadas en la bibliografía sobre modelado de formula-

http://www.ontologymatching.org/

http://www.ontologymatching.org/


rios emplean técnicas de correspondencias semánticas que pueden dividirseen dos grandes bloques: aquellas que encuentran correspondencias semánti-cas simples, también llamadas uno a uno (1:1) [1, 20, 28, 46], y las que en-cuentran correspondencias compuestas o M a N (M:N) [21, 24]. Un ejemplode correspondencia de tipo 1:1 es, teniendo un atributo Title en un formula-rio y Name en otro formulario distinto, se establece una correspondencia entreambos. Un ejemplo de correspondencia de tipo M:N es, teniendo en un formu-lario un atributo Author y en otro formulario dos atributos First Name y LastName, se establece una correspondencia Author → First Name, Last Name.

4.2.5. Identificar información semántica avanzada

Dentro de esta información semántica avanzada se definen distintos con-ceptos como son: orden entre campos, tipo de atributo, agrupación de etique-tas y campos o relaciones lógicas, entre otros. La mayor parte de estos concep-tos están recogidos en [23].

En referencia al orden entre campos, un campo dentro de un formulariopuede depender de otro. Normalmente esta dependencia implica que al serrellenado un campo, otro que esté relacionado a él puede cambiar su valor oincluso desaparecer [38]. Generalmente, este orden tiene su significado al exis-tir cierta relación semántica entre campos. Un ejemplo puede ser una lista deselección de países y otra de ciudades, por regla general, al seleccionar un país,la lista de ciudades se restringirá a aquellas perteneciente al país seleccionado.

En la Figura §B.1, si se rellena el campo after, el campo before puedecambiar su valor mediante técnicas dinámicas para que el rango sea correcto.

Otra información semántica que se puede identificar es el tipo de atributo.Una vez descubiertos los atributos que ofrece un formulario, hay que distin-guir si son atributos que sirven para consultar los datos o, por el contrario, seemplean para definir cómo se presentan los resultados [52]. Los atributos pue-den ser de dos tipos: de dominio (consultan datos) y de presentación (definencómo se presentan los resultados).

En la Figura §B.1, Title sirve para restringir la consulta a aquellos libroscuyo título sea el que se rellene en el campo que corresponda, es decir, esun atributo de dominio. Mientras que Display es un atributo de presentaciónporque sirve para formatear los datos de salida y mostrar un número determi-nado de registros por página.

La agrupación de etiquetas y campos es información semántica avanzadaque puede ser extraída del formulario. Un atributo no tiene por qué estar aso-


ciado a un único campo del formulario de búsqueda (con su correspondienteetiqueta), sino que se puede representar como un conjunto de campos y eti-quetas.

Los campos de una agrupación pueden ser de dos tipos: dominio y res-tricción. Un campo de tipo dominio es aquel que se emplea para especificarvalores de dominio, es decir, valores que sirven para restringir los datos a con-sultar. En la Figura §B.1, Publication Year es una agrupación cuyos camposde dominio son las dos listas de selección. Un campo de tipo restricción esaquel que impone cierta restricción a los campos de tipo dominio. En la Figu-ra §B.1, los radios que acompañan a Title son de tipo restricción.

Los campos de tipo dominio pueden formar a su vez tres tipos de relacio-nes entre sí: rango, parte y grupo. En la de tipo rango, se relacionan dos o máscampos que especifican un rango. En la Figura §B.1, Publication Year especi-fica un rango de año de publicación. En la de tipo parte, se relacionan camposque forman parte de un todo. En la Figura §B.1, First Name y Last Name for-man parte de Author. Por último, en la relación de tipo grupo, se relacionancampos que forman un grupo sólo cuando son de tipo radio o checkbox. En laFigura §B.1, Format es un único atributo con varios campos de tipo checkbox.

Además de estas relaciones entre campos de dominio, puede extraerse másmetainformación como el tipo de valor de un campo, el valor por defecto quetoma y la unidad del valor. En cuanto al tipo de valor, aunque en HTML todoslos campos de un formulario de búsqueda son enviados como texto al servi-dor, cada campo del formulario tiene su tipo de valor semántico. Se definencomo los tipos de datos de una variable en cualquier lenguaje de programa-ción. En la Figura §B.1, Title no tiene ningún tipo (tipo texto, por defecto), sinembargo, Publication Year es un entero y Price Range es de tipo moneda.El valor por defecto de un campo es el valor que toma un campo cuando elformulario es presentado en el navegador desde la aplicación, es decir, el va-lor que toma el campo sin modificar el formulario. En la Figura §B.1, el valorpor defecto de Display es 10. La unidad de un campo está asociada al valorque se asigna al campo. En la Figura §B.1, Price Range se expresa en dólaresde EEUU.

4.2.6. Relaciones lógicas

Al rellenar los campos de un formulario de búsqueda y realizar un envíode dicho formulario, los valores formarán una consulta sobre la base de da-tos que hay tras el formulario. Una vez descubierto los atributos que ofrece elformulario, los valores de los campos darán valor a estos atributos. Los atri-

4.3. Propuestas de modelado 49

butos deben de combinarse de alguna manera para generar la consulta queserá enviada. Hay que estudiar las relaciones lógicas que se establecen entrelos atributos a la hora de formar las consultas para acceder a la base de datos.

En la Figura §B.1, cuando se consulta por Author y Title, ¿cómo es inter-pretada dicha consulta: ‘Author = ... AND Title = ...’ o ‘Author = ... OR Title =...’? Cuando se marca más de un formato, por ejemplo, Hardcover y Paperback,¿se forma ‘Format = Hardcover AND Format = Paperback’ o ‘Format = Hard-cover OR Format = Paperback’?

4.2.7. Extraer capacidad de consulta

La capacidad de consulta de un formulario de búsqueda engloba las distin-tas formas por las que un formulario puede ser consultado. Un formulario, alestar compuesto de campos que permiten filtrar la información, puede versecomo una vista o conjunto de vistas, en el sentido de base de datos tradicional,sobre los datos ofrecidos por la aplicación Web. Las vistas que implementa elformulario imponen una serie de criterios a los datos. La capacidad de consul-ta se refiere a las diferentes maneras de combinar estos criterios.

Un ejemplo de la capacidad de consulta del formulario de la Figura §B.1 esque el atributo Title se consulta mediante una caja de texto y que tiene tresrestricciones sobre el valor que se indique, si se formula una consulta que noesté comprendida entre estas tres restricciones, la consulta no será viable y nopodrá ser ejecutada.

La viabilidad de una consulta enviada sobre un formulario de búsqueda serefiere a si un formulario permite la ejecución de una consulta dada. A la horade estudiar dicha viabilidad, extraer la capacidad de consulta es fundamentalpara analizar si la consulta ejecutada sobre el formulario podrá ser llevada acabo o no.

4.3. Propuestas de modelado

A continuación, analizamos los distintos modelos de formularios de bús-queda presentes en las propuestas de la bibliografía estudiada. Se presenta,por cada propuesta, una descripción del modelo y un ejemplo explicativo queayude a comprenderlo.

A la hora de estudiar las correspondencias semánticas nos es necesario


First NameLast Name

TitlePublication Year

(a) Atributos del formulario deejemplo.

AuthorBookYear

WriterTitled

Publication Year

(b) Conjuntos de atributosañadidos.

Figura 4.1: Conjuntos de atributos de ejemplo.

contar con más de un formulario de búsqueda. Encontrar correspondenciascomienza con el descubrimiento de los atributos que ofrece un formulario debúsqueda. Así, para el formulario de la Figura §B.1, le corresponde los atribu-tos presentados en la Figura §??. Por simplicidad sólo se tendrán en cuenta losatributos presentados, sin contar todos los que realmente posee el formulario.

Además de los atributos presentados, añadimos dos conjuntos de atribu-tos que se ven en la Figura §??. A la hora de establecer las correspondenciassemánticas en los ejemplos, se emplearán los tres conjuntos de atributos.

4.3.1. Chang et al.

4.3.1.1. Descripción

El trabajo relacionado con el modelado de formularios de búsqueda deChang et al. está englobado dentro del proyecto Metaquerier [12]. Metaquerierpersigue una integración a gran escala de aplicaciones que pertenecen a lahidden Web, recorriendo toda la Web en busca de fuentes de información yanalizando e integrando dichas fuentes para que puedan ser consultadas porel usuario. Metaquerier ha sido desarrollado en la Universidad de Illinois enUrbana-Champaign (UIUC). Algunos miembros destacados de esta propuestason Kevin Chen-Chuan Chang y Bin He.

En [56] se describe un modelo y un método para extraer dicho modelo demanera automática. Para modelar e integrar bases de datos Web, lo primeroque se debe hacer es entender lo que quiere decir un formulario de búsque-da, es decir, qué capacidad de consulta posee. Esta propuesta se basa en laobservación de que los formularios de búsqueda poseen cierta estructura con-certada, compartiendo bloques de construcción comunes. Se parte de la hipó-tesis de que existe una sintaxis, no establecida a priori, que guía la creaciónde formularios de búsqueda aunque se traten de fuentes distintas. Dicha hi-


<form action=”…”><table><tbody><tr>...

Token 1

Token 2

Token 3

...

Form Model

2P-Grammar

Tokenizer

Best-effort parser

Merger

Figura 4.2: Extracción de capacidad de consulta de un formulario.

pótesis transforma el problema en uno nuevo: los formularios de búsqueda seven ahora como un lenguaje visual, la composición de éste lenguaje da lugara una gramática no establecida a priori. El entendimiento de la semántica setransforma en un problema de análisis sintáctico.

Un esquema de las actividades llevadas a cabo para la extracción del mo-delo de un formulario de búsqueda puede verse en la Figura §4.2. El proce-so de extracción comienza con la segmentación del formulario en partes mássimples, representando cada parte un elemento visual atómico del formulario.Cada átomo tiene un tipo (indicando si es texto o un control HTML), el valordel texto o identificador del control y su posición dentro del formulario.

Tras la segmentación, se utiliza un analizador sintáctico de mejor esfuerzo(Best-effort parser) y una gramática 2P (2P-Grammar) para construir múlti-ples árboles sintácticos parciales. La gramática 2P recibe dicho nombre por-que contiene tanto las Producciones (características de cualquier gramática)como las Preferencias que toman dichas producciones. Estas preferencias es-tablecen una relación de orden entre las reglas para útiles para desambiguar.Como la hipótesis de partida establece que todos los formularios de búsquedason construidos de la misma forma, la gramática será la misma para todos losformularios. Por último, se combinan los árboles obtenidos por el analizadorpara obtener el modelo semántico final, el módulo que lleva a cabo este paso


Figura 4.3: Producciones y patrones visuales de la gramática 2P.

es el Merger†1.

La gramática 2P es única para todos los formularios que se analizan conesta propuesta. En la Figura §4.3 [56] se observan algunas producciones de lagramática 2P y a la derecha de cada producción, el patrón visual que imple-menta. Gracias a esta gramática se analiza sintácticamente los formularios debúsqueda y se obtiene el modelo de formularios.

La propuesta descrita en [56] es sometida a un proceso de evaluación sobrelos formularios presentes en TEL-8 (ver el apartado §B.2 para más informaciónsobre los bancos de pruebas de las propuestas estudiadas). Se obtiene para el70 % de formularios de TEL-8 aproximadamente, una precisión y un recall de1.0.

Para la resolución del problema de las correspondencias semánticas, seproponen dos paradigmas: usando técnicas estadísticas o técnicas de mineríade datos. Las técnicas estadísticas se emplean en [20]. Se parte de dos obser-vaciones prácticas: existe una multitud de fuentes de datos que proporcionaninformación estructurada perteneciente al mismo dominio; mientras las fuen-tes proliferan, su vocabulario tiende a converger a un número limitado depalabras. Motivados por estas observaciones prácticas, se parte de la hipótesisde que existe un modelo de esquema oculto: modelo que describe cómo songenerados los esquemas a partir de un vocabulario finito de atributos con un

†1En http://metaquerier.cs.uiuc.edu/formext/results.html se exponen los resultados de la ex-tracción de la capacidad de consulta sobre una serie de formularios de búsqueda.

http://metaquerier.cs.uiuc.edu/formext/results.html


Traditional approaches

S2.Author = S3.WriterS1.Title = S2.Book

...

Statistical Schema Matching

...

Author WriterTitle Titled Book

S1

First NameLast Name


S2AuthorBookYear

S3WriterTitled

Publication Year

S1

First NameLast Name


S2AuthorBookYear

S3WriterTitled

Publication Year

Figura 4.4: Diferencias entre propuestas tradicionales y SSM.

comportamiento probabilístico. En el contexto del trabajo de Chang et al., unesquema es el conjunto de atributos que ofrece un formulario de búsqueda.

Motivados por dicha hipótesis, se explora un nuevo paradigma llamadostatistical schema matching (SSM). Este paradigma difiere de las propuestastradicionales en que, en lugar de extraer pares de atributos como resultado,se intenta encontrar un modelo que estructure los atributos presentes en losdistintos esquemas. Un ejemplo de las diferencias que existen entre las pro-puestas tradicionales y la propuesta comentada puede verse en la Figura §4.4[20].

Para llevar a cabo esta correspondencia estadística, se propone un fra-mework genérico llamado MGS (Modelling, Generation and Selection). MGSconsta de tres pasos: modelado, generación y selección de la hipótesis. Encuanto al modelado de la hipótesis, se especifica una estructura general delmodelo hipotético, esta estructura general debe capturar las cuestiones obje-tivo. Un ejemplo de cuestión objetivo puede ser encontrar sinónimos dentrode un vocabulario concreto. En el ejemplo de la Figura §4.4, el modelo hipo-tético para el descubrimiento de sinónimos corresponde al árbol de atributospresentado en statistical schema matching. Para la generación de la hipótesis,se generan todos los modelos consistentes con los esquemas observados conuna probabilidad distinta de cero. Por último, en la selección de la hipótesis,de todos los modelos consistentes, se escogen aquellos con una probabilidadsignificativa.


Utilizando el framework MGS como guía, se realiza una implementaciónconcreta de un algoritmo de correspondencias basado en sinónimos. Para pro-porcionar la estructura del modelo, se parte de una serie de premisas comola independencia mutua entre conceptos semánticos. Un formulario de bús-queda contiene muchos conceptos diferentes (por ejemplo, autor o categoría).Suponiendo que el desarrollador de un formulario de búsqueda puede selec-cionar todos los conceptos existentes posibles para formar un esquema, se asu-me que cuando se genera un esquema, diferentes conceptos son seleccionadosde manera independiente por dicho desarrollador.

Otra premisa es la exclusión mutua de sinónimos. Cuando existen múlti-ples sinónimos para un concepto se asume que, al generar un esquema, dossinónimos no serán seleccionados a la vez. La última premisa que se asumees que los conceptos no se solapan. Diferentes conceptos no se solapan en susemántica, es decir, conceptos distintos no compartirán atributos. Sin embar-go, esto no siempre ocurre así, hay veces en que los conceptos sí se solapan,por ejemplo, si se encuentran correspondencias del tipo Author, First Nameo Author, Last Name, al formar parte de un autor su nombre o apellido.

En [21] se emplean técnicas de minería de datos para establecer correspon-dencias semánticas complejas. Ya no se trata de encontrar una corresponden-cia 1 a 1, sino de agrupar elementos que forman parte del mismo concepto yencontrar correspondencias complejas de tipo M a N. Para dar solución a labúsqueda de las correspondencias complejas se trata dicha búsqueda comouna minería de correlaciones (correlation mining).

Esta minería se lleva a cabo mediante la búsqueda de patrones de simul-taneidad a lo largo de distintos esquemas: los atributos que forman agrupa-ciones están positivamente correlacionados porque suelen ocurrir simultánea-mente en los esquemas. Por el contrario, los atributos sinónimos están ne-gativamente correlacionados porque no suelen ocurrir simultáneamente. Porejemplo, First Name y Last Name están positivamente correlacionados porquese suelen dar simultáneamente en muchos esquemas, mientras que Author yWriter están negativamente correlacionados al ser sinónimos y no ser frecuen-te encontrarlos a la vez en un mismo esquema.

En lugar de emplear sólo dos esquemas para encontrar las corresponden-cias, esta propuesta usa todos los esquemas disponibles para encontrar una co-rrespondencia adecuada. Las correspondencias que se descubren usando estealgoritmo son del tipo M1 : M2 : M3 : ..., dependiendo del número de esque-mas tratado. Es decir, si tenemos los esquemas S1, S2 y S3 de la Figura §4.1, lascorrespondencias que se obtienen son de tipo: S1.atributo1 = S2.atributo1= S3.atributo1; en cambio, cuando se emplean esquemas dos a dos se ob-tienen las correspondencias: S1.atributo1 = S2.atributo1, S1.atributo1


= S3.atributo1, S2.atributo1 = S3.atributo1.

DCM es un framework que sirve para extraer las correspondencias com-plejas (Dual Correlation Mining). La motivación de este trabajo parte de laidea de transformar el problema de las correspondencias en un problema deminería. Realizando observaciones prácticas se obtienen dos premisas: algu-nos atributos pueden agruparse para formar un concepto más genérico, y dis-tintas fuentes pueden usar atributos diferentes para el mismo concepto. Estosatributos son de tipo sinónimo.

Ambos tipos de atributos (agrupados y sinónimos) forman las correspon-dencias complejas que se quieren extraer. DCM emplea dos pasos: la prepara-ción de los datos y la extracción de correlaciones. La preparación de los datosconsiste en la extracción de la capacidad de consulta del formulario de bús-queda empleando la propuesta descrita en [56]. Una vez extraída su capaci-dad, se realiza una serie de normalizaciones sobre los nombres y dominiosextraídos: se emplea un algoritmo de stemming, se normalizan palabras irre-gulares (por ejemplo, children a child) y se eliminan palabras vacías de unalista construida manualmente. El siguiente paso de la preparación de datos esel reconocimiento del tipo de valor de los atributos extraídos. Esto es útil paraidentificar homónimos (igual nombre con significados distintos). Para distin-guir entre atributos se emplea su nombre y tipo de valor. El último paso de lapreparación de datos es la combinación sintáctica, se realiza una limpieza delos esquemas combinando sintácticamente atributos similares.

La extracción de correlaciones consta de tres pasos. Por un lado, el descu-brimiento de grupos donde se extraen los atributos positivamente correlacio-nados para formar grupos potenciales de atributos, sólo los grupos potencialesque tengan sinónimos (correlación negativa) con otros grupos podrán sobre-vivir. Por ejemplo, First Name y Last Name formarán grupo si existe algúnesquema que contenga Author, si no, no tiene sentido crear el grupo.

Dados los grupos potenciales, se extraen los atributos negativamente corre-lacionados para formar las correspondencias potenciales complejas. Por ejem-plo, una correspondencia compleja es First Name, Last Name = Author =Writer, porque los atributos están negativamente correlacionados (sinónimos)entre cualquier par de grupos. Una correspondencia potencial no debe inter-pretarse como correcta debido a la existencia de posibles conflictos entre lasmismas correspondencias. El último paso de la extracción de corresponden-cias es la selección de correspondencias en donde, para solventar los conflic-tos, se seleccionan las correspondencias más consistentes y adecuadas, asig-nando pesos a las correspondencias extraídas y estableciendo un ranking.


Figura 4.5: Ejemplo de fragmentos de un formulario.

4.3.1.2. Ejemplo

Al formulario de ejemplo de la Figura §B.1 se le aplica el proceso de seg-mentación. El resultado del proceso puede observarse en la Figura §4.5, en estecaso ponemos como ejemplo la segmentación del atributo Title. En la tabla,ID es la manera de identificar un elemento del formulario, Type es el tipo deelemento (si es texto o un campo) y <Field, Value> indica alguna cualidaddel elemento, como el nombre interno HTML o el valor del texto, también seincluye las coordenadas que toma en el formulario el elemento.

El identificador s0 se refiere a la etiqueta “Title” que es de tipo texto y tieneuna posición en el formulario determinada por una serie de coordenadas. t0 serefiere a la caja de texto para especificar valores, el nombre del campo HTMLes ‘title’. r0, r1 y r2 son los diferentes radios que tienen todos el mismo nombreHTML: ‘field-1’. Por último, s1, s2 y s3 son los textos que acompañan a losradios y cuyos valores son “Title word(s)”, “Start(s) of title word(s)” y “Exactstart of title”.

Con los fragmentos obtenidos, se aplica el analizador sintáctico y la gra-mática 2P para obtener árboles parciales de análisis sintáctico. Los árbolesparciales se combinan y se obtiene como resultado la capacidad de consultadel formulario, como se ve en la Figura §4.6. Esta Figura la hemos obtenidomanualmente dando el mismo estilo que se puede observar en la página deMetaquerier (http://metaquerier.cs.uiuc.edu/formext/results.html).

Observamos que se han extraído como atributos Last Name y First Name

http://metaquerier.cs.uiuc.edu/formext/results.html


Figura 4.6: Ejemplo de extracción de capacidad de consulta.

S1.First Name, Last Name = S2.Author = S3.WriterS1.Title = S2.Book = S3.TitledS1.Publication Year = S2.Year = S3.Publication Year

Figura 4.7: Correlaciones entre atributos de los esquemas de ejemplo.

con sus cajas de texto asociadas, Title con los campos de restricción comooperadores en una lista de selección y la caja de texto asociada. PublicationYear y Price Range como rangos y sus campos asociados. Format como elgrupo de los tres checkboxes que lo forman, sus valores se han incluido en unalista de selección. Check bargains? de tipo booleano (True o False) y Displaycon la lista de selección asociada.

Una vez extraída la capacidad de consulta, vamos a aplicar el algoritmoDCM de correlaciones para los esquemas S1, S2 y S3 de la Figura §4.4. Las co-rrelaciones que se extraen se pueden ver en la Figura §4.7. En este caso, FirstName y Last Name han sido agrupados y relacionados con Author y Writer alser sinónimos. Title, Book y Titled forman otra equivalencia; PublicationYear y Year la última al coincidir su lista de valores.

4.3.2. Meng et al.



El trabajo de Meng et al. se centra en las técnicas de tipo metasearch condos sistemas: WISE-Integrator [24] y WISE-iExtractor [23] desarrollados am-bos en la Universidad de Illinois en Chicago. Weiyi Meng y Clement Yu sonprofesores en dicha universidad y participan en los proyectos WISE.

Meng et al. presentan en [23] una propuesta de modelado de formulariosde búsqueda a tres niveles que captura información semántica avanzada. Elnivel superior ofrece información de la aplicación Web y de los atributos queofrece el formulario. El segundo nivel describe cada atributo en detalle. Porúltimo, el tercer nivel ofrece información de posibles agrupaciones de etique-tas y campos que pueden formar un único atributo. En el nivel superior, elmodelo del formulario se representa como F = (S, A1, A2, ..., An, Cf), S es lainformación de la aplicación Web (URL, nombre del servidor, método de envíoHTTP, etc.), A1, ..., An es una lista ordenada de los atributos de la interfaz, yCf es la restricción del formulario, es decir, la relación lógica que existe entrelos atributos al enviar el formulario.

En el segundo nivel, cada atributo Ai es representado por (L, P, DT, DF, VT,U, Re, Fj, Fj+1, ..., Fk, Ca) en donde L es la etiqueta del atributo Ai. En la Figura§B.1, “Title” es la etiqueta que referencia al campo para consultar el título deun libro. P es la posición del atributo en el formulario de búsqueda.

DT es el tipo de dominio que contabiliza los distintos valores que pue-den usarse para realizar consultas sobre un atributo. Los posibles valores queacepta el modelo son: rango, finito, infinito y booleano. El tipo booleano sólose aplica a los atributos que consisten en un único checkbox (selección de sí ono). Un atributo tiene tipo infinito cuando se trata de una caja de texto. El tipofinito se aplica sobre las lista de selección. Aunque estas son las reglas gene-rales, puede existir cajas de texto o listas de selección asociadas a rangos. Enla Figura §B.1, Check bargains? es un atributo de tipo booleano, PublicationYear de tipo rango cuyos campos son listas de selección, Price Range de tiporango cuyos campos son cajas de texto, Title de tipo infinito y Display detipo finito.

DF es el valor por defecto del atributo, marcado en el código fuente HTMLde manera explícita. VT es el tipo de valor. Aunque en HTML todos los cam-pos de un formulario de búsqueda son enviados como texto al servidor, cadacampo del formulario tiene su tipo de valor semántico. Los tipos de valorespermitidos por el modelo son: date, time, datetime, currency, id, number ychar. Atributos similares de diferentes formularios de búsqueda dentro delmismo dominio temático deben tener los mismos tipos de valores. En la Figu-


ra §B.1, Publication Year es de tipo number y Price Range de tipo currency.U es la unidad del atributo y define el significado del valor del atributo (porejemplo, kilo es una unidad para el peso). No todos los atributos tienen uni-dades: el autor de un libro carece de unidad. En la Figura §B.1, Price Rangetiene como unidad US$.

Re es el tipo de relación con los campos del dominio. Existen tres tiposde relaciones: rango, grupo o parte. En la Figura §B.1, Price Range de tiporango, Format de tipo grupo y Author de tipo parte, con First Name y LastName como las partes que lo conforman. Fj, Fj+1, ..., Fk es la lista ordenada decampos de dominio de un atributo. Por último, Ca es la lista de campos derestricción que se aplican sobre el atributo. En la Figura §B.1, los campos detipo radio que acompañan a Title son de restricción.

En el tercer nivel, cada campo de dominio Fi es representado por (Le, N,Fme, V, DV). Le es la etiqueta del campo. N es el nombre interno del códigofuente HTML. Fme es el formato, por ejemplo, caja de texto, lista de selección,radio o checkbox. V es el conjunto de valores del campo. DV es el valor pordefecto. Por ejemplo, en el formulario de ejemplo de la Figura §B.1 un camposería la primera lista de selección de Publication Year con etiqueta “after”.

Cuando un atributo tiene asociados múltiples campos, dichos campos seclasifican en dos tipos: dominio y restricción. Los campos de dominio son usa-dos para especificar valores del dominio para un atributo, mientras que loscampos de restricción se usan para añadir restricciones sobre los campos dedominio. En la Figura §B.1, la caja de texto del atributo Title es de tipo domi-nio y los radios que la acompañan (“Title word(s)”,...) son de tipo restricción.

También son importantes las relaciones lógicas que se producen entre atri-butos. Los atributos se pueden combinar de manera lógica de muchas formasdiferentes para acceder a la base de datos que está oculta tras el formulario debúsqueda. Existen cuatro posibilidades de relaciones: la conjunción, en la quetodos los atributos se combinan usando un operador AND, es decir, todas lascondiciones deben ser satisfechas al mismo tiempo. La disyunción, en dondetodos los atributos se combinan usando un operador OR, es decir, al menosuna condición debe ser satisfecha. La exclusiva ocurre cuando sólo un atribu-to puede ser elegido para formar consultas. Y, por último, la híbrida es unacombinación de los tres casos anteriores.

Un esquema general del proceso de extracción del modelo comentado pue-de verse en la Figura §4.8. A continuación pasamos a detallar el proceso deextracción.

La extracción de etiquetas y de campos es necesaria para empezar a mode-


<form action=”…”><table><tbody><tr>...

t|tt|ee|...

Form Model

IEXP Extractor

Fields and labels groups

Domain/constraint field classifier

Exclusive attributes

Domain/constraint field classifier

Domain fields relationship

classifier

Attributes metainformation

classifier

Logic relationship

classifier

Figura 4.8: Esquema de la extracción del modelo de un formulario.

lar un formulario de búsqueda, sin embargo, no es suficiente ya que se deseaobtener los atributos que ofrece un formulario. Los atributos son formadospor etiquetas y campos relacionados. Para la extracción, se observa que las eti-quetas y los campos que forman parte de un mismo atributo tienen un patrónvisual concreto y suelen estar cercanos unos a otros.

Lo primero es obtener una expresión del formulario de búsqueda llamadaIEXP (Interface EXPression). Esta expresión se construye analizando el códigofuente del formulario y consiste en una cadena donde se concatenan una ‘t’cuando se analiza un texto del formulario objetivo, una ‘e’ cuando se analizaun campo y una ‘|’ para denotar un cambio de fila.

En este paso se agrupan las etiquetas y campos que semánticamente corres-ponden al mismo atributo, además de encontrar la etiqueta apropiada paracada grupo. La idea de este paso es que, dado un campo en una fila, observarlos textos de la misma fila o dos filas posteriores a la actual para encontrar laetiqueta que mejor lo defina. Al final, todos los campos con la misma etiquetaserán agrupados.

Para identificar si una etiqueta define correctamente a un campo se usancinco medidas como son:

1. Analizar si existen dos puntos al final del texto, frecuentemente una eti-queta de atributo termina en dos puntos. La etiqueta de Publication


Year en la Figura §B.1 es un ejemplo.

2. Similitud textual entre texto y nombre interno del campo. En la Figura§B.1, la lista de selección que acompaña a Display tiene como nombreinterno HTML ‘display’.

3. La distancia textual entre campo y texto es relevante ya que la etiquetade un atributo y sus campos suelen encontrarse cercanos unos a otros enel formulario.

4. El alineamiento vertical de campos y etiquetas de distintas filas. En laFigura §B.1, la etiqueta “Title” está alineada verticalmente con la caja detexto del atributo Title.

5. La fila actual es prioritaria con respecto al resto. Aunque se analicen otrasfilas, la fila en la que se encuentra el campo en estudio tiene mayor prio-ridad.

El resto de características estudiadas que pueden añadirse al modelo sonextraídas empleando clasificadores Bayesianos. Al diferenciar entre camposde tipo dominio o restricción hay que tener en cuenta que las cajas de tex-to no pueden ser usadas para especificar campos de restricción. Los camposde tipo radio, checkbox o lista de selección pueden aparecer como campos derestricción. Un atributo que conste de un único campo no tiene campos de res-tricción. Un atributo consistente en sólo radios o checkboxes no tiene camposde restricción.

Se identifica primero aquellos atributos que sólo contienen un campo oaquellos cuyos campos son todos radios, checkboxes o cajas de texto. Estosatributos son considerados de tipo dominio. Para el resto de atributos, se apli-ca un clasificador que usa como características el nombre del campo, el forma-to, la posición relativa en la lista de campos y los valores del campo.

Un atributo que tenga múltiples campos de dominio puede tener una rela-ción con sus campos de tipo grupo, rango o parte. De tipo grupo son aquellosatributos cuyos campos son todos radios o checkboxes. Para el tipo rango oparte, se emplea un clasificador que usa como características el nombre delatributo, los nombres de los campos, las etiquetas de los campos y los valoresde los campos.

Para analizar si la relación lógica es de tipo conjunción, disyunción o hí-brida habría que realizar consultas a la aplicación y analizar los resultadosdevueltos. Al ser difícil enviar consultas apropiadas de manera automática, seasume que todos los atributos se relacionan mediante conjunción.


La evaluación de la propuesta presentada en [23] se realiza tomando unaserie de formularios escogidos al azar de entre siete dominios temáticos. Enel nivel de campo, se obtienen para el dominio de libros una precisión del97.7 % y para el dominio de películas del 93.8 %. Estos porcentajes se obtienenmidiendo el número total de campos analizado en todos los formularios de undominio y los que se han identificado su etiqueta correctamente. En el nivel deatributo, para el dominio de libros se obtiene una precisión del 94.8 % y en eldominio de películas un 91.3 %. Los porcentajes son calculados analizando losatributos de los formularios manualmente y comparando con los obtenidospor el sistema.

La extracción de la capacidad de consulta de un formulario es abordada en[52]. Se propone un algoritmo cuyo objetivo es extraer las consultas atómicas(AQ, Atomic Queries) de un formulario de búsqueda. Las AQ son consultasmínimas aceptadas por los formularios de búsqueda, independientemente desi devuelven resultados o no. Es decir, las AQ las forman los atributos obliga-torios de un formulario.

Se detectan las AQ mediante el envío de consultas a la aplicación. Al re-llenar los campos de la consulta, los valores de las cajas de texto deben deproporcionarse de alguna manera, ya que no es posible rellenar de forma au-tomática dichos campos.

Este descubrimiento de las AQs es fundamental a la hora de estudiar laviabilidad de una consulta ejecutada sobre un formulario de búsqueda. Si enla consulta no se especifican los campos mínimos requeridos por el formulario,la consulta no podrá ser ejecutada sobre dicho formulario.

Para saber si una consulta ha sido satisfactoria o no (en el sentido de siha fallado al ser enviada, si no ha fallado, no importa si devuelve datos ono) se emplea un clasificador de páginas de resultados. Las evidencias de quela consulta ha sido satisfactoria son que existen secuencias en la página deresultados. Dos tipos de secuencias pueden existir, una para los registros y otrapara las páginas de resultados. Otra evidencia es que el tamaño de la páginade resultados es mayor que cuando no es satisfactoria. Por último, la existenciade patrones en el resultado implica que la consulta ha sido satisfactoria.

Una evidencia de que la consulta no ha sido satisfactoria es que se gene-ran mensajes de error. Otra evidencia es que la página de resultados es muysimilar a la del formulario o que el tamaño de la página de resultados es me-nor que cuando sí es satisfactoria. En la Figura §B.1, la única AQ existente esLast Name que coincide con que es el único campo obligatorio a rellenar delformulario.


F = (S, A1, A2, ..., An, Cf)

Ai = (L, P, DT, DF, VT, U, Re, Fj, Fj+1, ..., Fk, Ca)

Fi = (Le, N, Fme, V, DV)

Figura 4.9: Modelo de Meng et al..

En [24] se describe cómo resolver el problema de las correspondencias se-mánticas. Se emplean técnicas de lenguaje natural (analizar si dos atributosson sinónimos, por ejemplo) y basadas en el valor del atributo. Antes de co-menzar el proceso de la búsqueda de correspondecias, se realiza un normali-zado de los atributos empleando algoritmos de lenguaje natural (por ejemplo,stemming) y una serie de heurísticas que incluyen pasar el texto a minúscula,eliminar todo el contenido entre paréntesis y algunas otras.

El algoritmo usado para identificar las correspondencias positivas constade tres pasos: agrupar atributos de todos los formularios cuyo nombre exac-to coincidan, unir los grupos producidos en el paso anterior basándose enla equivalencia de valores y semántica de nombres, y determinar el nombrerepresentativo de cada grupo producido en el paso anterior, se determina elnombre del atributo contabilizando la aparición mayor en los formularios.

Meng et al. proponen, además de la búsqueda automática de correspon-dencias semánticas, la intervención del usuario para descubrir corresponden-cias que no hayan sido identificadas y eliminar correspondencias que no seanválidas [55]. Estas intervenciones del usuario consisten en responder una seriede preguntas propuestas por el sistema.

4.3.2.2. Ejemplo

Aplicaremos los pasos descritos en [23] sobre el formulario de ejemplo dela Figura §B.1. Recordemos que un formulario se representa como muestra laFigura §4.9.

El formulario se expresa como se puede ver en la Figura §4.10, es decir, sehan detectado 7 atributos. Posteriormente, en la Figura §4.11 se analizan losatributos Author, Title, PublicationYear y PriceRange. En la Figura §4.12 se


BooksExample = (∅,Author, Title, PublicationYear, PriceRange,

Format, CheckBargains, Display,Author AND Title AND PublicationYear AND

PriceRange AND Format AND CheckBargains AND Display)

Figura 4.10: Modelo del formulario de ejemplo.

analizan los atributos Format, CheckBargains y Display. De esta manera seobtiene el modelo del formulario de ejemplo.

Para extraer la capacidad de consulta del formulario, se aplicará el algorit-mo propuesto en [52], resultando que la única consulta atómica es Last Name,que coincide con que es el único campo obligatorio del formulario.

Por último, aplicamos el algoritmo de búsqueda de correspondencias sobrelos formularios S1, S2 y S3 de la Figura §4.4. En el primer paso se forman losocho grupos que pueden verse en la Figura §4.13. Estos grupos se han forman-do pasando a minúscula los caracteres y aplicando un algoritmo de stemming.El grupo 3 y 4 ha agrupado a Title y a Publication Year respectivamente porquelas cadenas resultantes eran exactamente iguales.

Una vez vista la separación en grupos generada en el primer paso, en elsegundo paso se unen los grupos 3 y 6, al ser 6 más genérico que 3; los grupos4 y 7 porque los valores son iguales (lista de valores de 2000 a 2009); los grupos5 y 8 al ser sinónimos, además de unirse el grupo 1 y 2 por formar parte unode otro (“first name” y “last name” son parte de “author” y “writer”).

Tras este procesamiento quedan tres grupos definitivos a los que hay quenombrar. En el tercer paso se le asigna un nombre global a los grupos quedan-do definitivamente como se muestra en la Figura §4.14. Los nombres globaleshan sido asignados contando la aparición mayor en los formularios, hay quecomentar que en el grupo de author podría haberse cogido cualquier nom-bre, porque no hay suficientes evidencias para decidir, pero en un caso realcon más de tres formularios normalmente predomina Author frente a otrasposibilidades.

4.3.3. Álvarez et al.


Author = (“Author”, 0, infinite, ∅, char,∅, part, AuthorLN, AuthorFN, ∅)

AuthorLN = (“Last Name *”, author_last, textbox, ∅, ∅)AuthorFN = (“First Name”, author_first, textbox, ∅, ∅)

Title = (“Title”, 1, infinite, ∅, char,∅, part, TitleT, TitleR)

TitleT = (∅, title, textbox, ∅, ∅)TitleR = (∅, field-1,

“Title of word(s)”, “Start(s) of title word(s)”,“<i>Exact</i> start of title”,

“Title of word(s)”)

PublicationYear = (“Publication Year:”, 2, range,∅, number, ∅, range,PublicationYearA, PublicationYearB,∅)

PublicationYearA = (“after”, year_after, select,2000, ..., 2009, 2000)

PublicationYearB = (“before”, year_before, select,2000, ..., 2009, 2000)

PriceRange = (“Price Range:”, 3, range,∅, currency, US$, range,PriceRangeL, PriceRangeH, ∅)

PriceRangeL = (“between US$”, price_between_low,textbox, ∅, ∅)

PriceRangeH = (“and US$”, price_between_high,textbox, ∅, ∅)

Figura 4.11: Atributos del formulario de ejemplo.


El trabajo estudiado de Álvarez et al. está incluido dentro del prototipode crawler de la hidden Web llamado DeepBot [1]. Este crawler es capaz de,


Format = (“Format:”, 4, finite,∅, char, ∅, group,Format1, Format2, Format3, ∅)

Format1 = (“Hardcover”, format, checkbox, false, true, false)Format2 = (“Paperback”, format, checkbox, false, true, false)Format3 = (“e-Books & Docs”,

format, checkbox, false, true, false)

CheckBargains = (“Check bargains?:”, 5, boolean,false, char, ∅,group, CheckBargains1, ∅)

CheckBargains1 = (∅, bargains, checkbox,false, true, false)

Display = (“Display:”, 6, range, 10, number, ∅,part, DisplayD, ∅)

DisplayD = (∅, display, select, 10, 20, 10)

Figura 4.12: Atributos del formulario de ejemplo (continuación).

1.- S1.first name2.- S1.last name3.- S1, S3.titl4.- S1, S3.public year5.- S2.author6.- S2.book7.- S2.year8.- S3.writer

Figura 4.13: Grupos del primer paso de la búsqueda de correspondencias.

recibiendo una serie de tareas específicas de recolección de datos, aprender aejecutar consultas sobre formularios.


author:S1.first name, S1.last name = S2.author = S3.writer

titl:S1, S3.titl = S2.book

public year:S1, S3.public year = S2.year

Figura 4.14: Grupos finales de la búsqueda de correspondencias.

Como entrada a DeepBot se debe aportar una serie de definiciones de do-minio especificadas por el usuario. Las definiciones de dominio consisten enuna serie de atributos, con un nombre y un conjunto de alias para cada nom-bre.

Un atributo representa un campo del formulario que es relevante en latarea de recolección de datos. Los alias de un atributo representan etiquetasalternativas para identificar un campo de un formulario. Cada atributo poseeun índice real específico (entre 0 y 1), indicando cuánto de probable es que unformulario que contenga dicho atributo sea relevante para el dominio.

Un ejemplo de definición de dominio para venta de libros puede verse enla Figura §4.15 [1]. Se observan varios atributos como Title, Author o ISBN consus respectivos alias y el índice específico. Como se observa, si un formulariocontiene un campo ISBN es mucho más probable que sea un formulario deventa de libros que si existe un campo llamado Subject.

Además de atributos y alias, las definiciones de dominio contienen una se-rie de consultas predefinidas para ejecutar sobre los formularios. Las consultasson del tipo: atributo-valor. Un ejemplo de estas consultas es ‘Blade Runner’para Title y ‘Philip K. Dick’ para Author en la Figura §4.15. Cada definiciónde dominio posee un umbral de relevancia. Los índices específicos y el um-bral se emplean para determinar si un formulario es relevante en un dominiotemático aplicando una fórmula determinada. En la definición de dominio dela Figura §4.15, el umbral de relevancia tiene como valor 0.9.

Para asociar los campos del formulario a los atributos de una definición dedominio dada, es necesario extraer las etiquetas que acompañan a los camposen el formulario. La extracción de las etiquetas se realiza mediante una serie


Figura 4.15: Ejemplo de definición de dominio para venta de libros.

de heurísticas basadas en distancias visuales. Se toman todos los textos de lapágina y se calcula la distancia visual entre los campos del formulario y lospropios textos. Empleando la API del navegador se toman las coordenadasdel rectángulo que engloba a cada campo del formulario y los rectángulos delos textos, se calcula la distancia mínima y el ángulo entre rectángulos.

Una vez calculadas distancias y ángulos, el objetivo es obtener los textossemánticamente relacionados con los campos del formulario por su proximi-dad. Primero se lleva a cabo una preselección de los mejores textos para cadacampo: se añaden a la lista de textos de cada campo los textos con la menordistancia d, se añaden a la lista de textos de cada campo los textos con dis-tancia k · d, siendo k un parámetro configurable (de esta forma se descartantextos muy lejanos), y los textos con distancias similares son ordenados deacuerdo a su ángulo. Tienen preferencia los textos que están alineados con elcampo, también tiene más peso izquierda con respecto a derecha y arriba conrespecto abajo. Estas suelen ser las posiciones que ocupan las etiquetas en losformularios.

Una vez obtenida la lista de posibles textos de cada campo, se aplican doscondiciones: un texto sólo puede estar en la lista de un único campo y ca-da campo debe tener un texto asociado. La idea de la primera condición esque, al finalizar el proceso, se debe asociar de manera no ambigua un texto aun campo del formulario. La idea de la segunda condición es que, un campode un formulario, siempre tiene un texto asociado que permite identificar sufuncionalidad. Al finalizar este paso se obtienen las etiquetas asociadas a los


campos del formulario.

El siguiente paso es detectar los campos que se corresponden con atributosdel dominio. Se distinguen dos tipos de campos: los delimitados y sin delimi-tar. Los campos delimitados son aquellos que tienen una lista finita de posiblesvalores, campos de tipo lista de selección, checkbox o radio. Los campos sindelimitar pueden tomar cualquier valor, un ejemplo de este tipo de camposson las cajas de texto.

La idea básica para la correspondencia entre campos y atributos es me-dir la similitud textual entre las etiquetas obtenidas en el paso anterior y losatributos y sus alias. Para los campos delimitados, se tiene en cuenta ademáscomparaciones entre la lista de valores de dicho campo y los valores presentesen las consultas predefinidas de cada atributo. Por ejemplo, si en la definiciónde dominio de la Figura §4.15 tenemos una consulta para Format con valor“Hardcover”, en el formulario de la Figura §B.1 un posible valor para Formates “Hardcover”, por tanto, se podría establecer la correspondencia entre elatributo y la etiqueta.

Al final, se obtiene una asociación entre campo del formulario y atributode la definición de dominio con un cierto grado de confianza equivalente alvalor de similitud obtenido.

En el paso anterior se han obtenido una serie de asignaciones entre camposy atributos [A1, ..., Ak], cada asignación tiene asociada un grado de confianzaci. Para determinar si un formulario es relevante, se emplea la fórmula:

k∑

i=1

ci · si > µ (4.1)

Siendo si el índice específico de cada atributo y µ el umbral de relevanciadel dominio.

Por último, cuando ya se han realizado las correspondencias y calculado larelevancia de los formularios, se ejecutan las consultas predefinidas. Se rellenael formulario objetivo completando cada campo con el valor especificado en laconsulta a ejecutar y se realiza un envío del mismo. En numerosas ocasiones,provocar un evento SUBMIT sobre el formulario no es una simulación real delo que haría un usuario. Normalmente, se suele pulsar un enlace o botón pararealizar el envío que llevan a cabo ciertas tareas dinámicas mediante códigoen el lado cliente. El sistema intenta realizar la misma labor que un usuarioempleando una serie de heurísticas como simular un click sobre botones oimágenes. Si el envío del formulario no se realiza, se termina generando unevento SUBMIT sobre el formulario.


Titlef3 Title words(s)

f1 f2f3 f5 f6f7 f8f11f41 f42 f43f10f91 f92 f93

Figura 4.16: Esquema y extracción de etiquetas de formulario de ejemplo.

Se evalúa la propuesta haciendo uso de formularios de tres dominios te-máticos: venta de libros, música y películas. Para asociar un dominio a unformulario la precisión es de 1.0 en todos los dominios y el recall cercano auno (entre 0.97 y 1.0). En las asociaciones entre atributos de la definición dedominio y los campos del formulario la precisión y el recall son cercanos a 1.0.Por último, en la extracción de etiquetas para el dominio de libros la precisiónes de 0.82 y el recall de 0.88, en el dominio de música es 0.82 y 0.98 y en eldominio de películas es 0.87 y 0.91, respectivamente.

4.3.3.2. Ejemplo

Aplicaremos las técnicas vistas sobre el formulario de la Figura §B.1 y conla definición de dominio de la Figura §4.15. En la Figura §4.16 puede verse unesquema del formulario de ejemplo y cómo se van calculando las distancias yángulos entre etiquetas y campos.

Una vez extraídas las etiquetas hay que buscar similitudes entre las eti-quetas y los atributos y alias de la definición de dominio. De esta manera, losúnicos campos que se extraen son dos: Title con confianza 1, al tener coinci-


f1 f2TITLE f5 f6f7 f8f11f41 f42 f43f10f91 f92 f93FORMAT

Figura 4.17: Asignación de atributos sobre el formulario de ejemplo.

dencia exacta entre cadenas, y Format con igual confianza, las dos asignacionespueden verse en la Figura §4.17.

Atendiendo a la fórmula que calcula si el formulario posee relevancia en eldominio quedaría, para las dos asignaciones:

k∑

i=1

ci · si = (4.2)

sTITLE · cTITLE + sFORMAT · cFORMAT =

0.6 · 1 + 0.25 · 1 = 0.85

0.85 < µ = 0.9

Por tanto, como no supera el umbral de relevancia (µ) impuesto por la de-finición de dominio, el formulario no sería relevante para el dominio temático.

4.3.4. Garcia-Molina et al.


El trabajo de Garcia-Molina et al. gira en torno al proyecto HiWE (Hid-den Web Exposer) [46] y al estudio de formularios HTML en PDAs [28]. Encuanto a HiWE, se propone una arquitectura genérica para implementar uncrawler que acceda a la hidden Web. Una vez presentada dicha arquitectura,es utilizada para implementar HiWE. Con respecto al trabajo con formularios


BotónSearch Books!

Form

Books Example

First NameLast NameTitlePublication YearPrice RangeFormatCheck bargains?Display

(a) Formulario de ejemplo en unaPDA de pantalla pequeña.

BotónSearch Books!

Form

Books Example

First NameLast Name

TitlePublication YearPrice RangeFormatCheck bargains?Display

…………………………………...

(b) Selección de apellido de unautor en PDA.

Figura 4.18: Ejemplo de formulario en PDA.

HTML en PDAs, proponen un diseño para mostrar y manipular formulariosHTML en pantallas de PDAs pequeñas. El reto es encontrar automáticamen-te una correspondencia entre el campo de un formulario y la etiqueta que loacompaña.

Un ejemplo del formulario de la Figura §B.1 puede verse en la Figura §??.La idea del trabajo de Garcia-Molina et al. es que, al tener este formulario enpantalla, el usuario pueda seleccionar una etiqueta y rellenar el campo asocia-do a dicha etiqueta. Un ejemplo del funcionamiento puede verse en la Figura§?? donde el usuario ha seleccionado el apellido del autor para rellenar algúnvalor.

El trabajo de Garcia-Molina et al. en PDAs intenta encontrar una etiquetapara cualquier campo de un formulario. La idea es, dado un formulario, porcada campo que contenga el formulario encontrar una etiqueta aclaratoria quelo defina. Se proporcionan una serie de algoritmos que pueden ser usadosconjuntamente para realizar el descubrimiento de etiquetas.

Todos los algoritmos propuestos tienen dos pasos: la partición en trozosy la selección de etiquetas. En cuanto a la partición en trozos, toda la páginaHTML recibida es partida en pequeños trozos de código que están delimita-dos por etiquetas de HTML, como por ejemplo, texto de párrafos, celdas detablas o los propios campos de los formularios. El resultado de este paso esuna lista ordenada con todos los trozos de la página HTML. En la selección deetiquetas, para cada campo del formulario que se encuentra en la lista de tro-


zos, se selecciona una cadena de texto de los trozos vecinos que es la elegidacomo el mejor texto que describe al campo.

Para la selección de etiquetas se proponen los siguientes algoritmos:

N-gramas: Tomando los 10 vecinos antes del campo actual y los 10 si-guientes, calculamos el n-grama entre cada texto vecino encontrado y elnombre interno del campo del formulario, eliminando espacios y carac-teres no alfanuméricos. El texto seleccionado es aquel con mayor pun-tuación.

Pongamos un ejemplo de n-gramas para n = 3 entre las palabras “ants”y “grants”. Para “grants” los trigramas generados son gra/ran/ant/ntsy para “ants” son ant/nts. La puntuación resultante es 2 al coincidir“ant” y “nts”.

Letra/Palabra y Palabra/Letra: Letra/Palabra es similar al de n-gramaspero, en lugar de eliminar espacios y caracteres no alfanuméricos, se to-ma la primera letra de la primera palabra y se concatena con la segundapalabra. Si los textos encontrados contienen menos de dos palabras latécnica no puede ser aplicada. Palabra/Letra es al contrario.

Para Letra/Palabra “First Name” se convierte en “FName”. Para Pala-bra/Letra “First Name” se convierte en “FirstN”.

Subcadena: Es otra variación del n-grama y se utiliza para analizar siuna palabra es una contracción de otra. Por ejemplo, “pwd” es una con-tracción de “Password”.

Tablas: Este algoritmo intenta emular cómo un usuario establece las co-rrespondencias entre etiquetas y campos cuando están dentro de tablas.Primero se observa si el texto analizado está en la misma celda que elcampo, si ocurre así, dicho texto es seleccionado como etiqueta del cam-po. En caso de que no exista texto en la misma celda, se busca el textoque esté en la celda inmediatamente a la izquierda. Si existe dicho texto,se elige como etiqueta. Si tampoco se encuentra etiqueta, se mira en lacelda de arriba, debajo y a la derecha. Cuando se encuentra el primertexto es seleccionado como etiqueta.

Previo y siguiente: En Previo se examinan los 10 trozos anteriores alcampo que se quiere establecer su etiqueta, cuando se encuentra el pri-mer texto, se elige como etiqueta. Siguiente es similar pero examinandohacia adelante.

Algoritmo NULL: Devuelve el texto del nombre interno del elementocomo etiqueta.


El trabajo de Garcia-Molina et al. en HiWE usa como modelo de formulariola expresión: Form = (F1, F2, ..., Fn, S, M), donde F1, F2, ..., Fn es un conjuntode campos del formulario, S es la información de envío a la aplicación asociadaal formulario y M es metainformación relativa al formulario. Un campo deun formulario puede ser del tipo: lista de selección, caja de texto, checkbox oradio. Cada campo posee su etiqueta y dominio, siendo la etiqueta el texto quelo acompaña y el dominio la lista de valores que puede tomar.

Para realizar la extracción automática del modelo se emplea una técnicadenominada LITE (Layout-based Information Extraction). Además del texto,LITE emplea información de la disposición visual de los elementos [45]. Segúnlos autores, es conveniente usar técnicas visuales por dos motivos principales:los elementos de una página que están visualmente próximos pueden no es-tarlo en el código fuente HTML y, aunque la especificación HTML incorporafacilidades para reflejar la semántica de los campos, normalmente no son utili-zadas por los desarrolladores dejando dicha semántica a la disposición visualde los elementos.

A partir de aquí, se emplean ciertas heurísticas para detectar las etiquetasde los campos como tomar sólo aquellas partes del formulario que afectendirectamente a la disposición de elementos y valores, capturar la disposiciónvisual aproximada del formulario eliminando imágenes e ignorando estilos oidentificar las piezas de texto que estén visualmente cercanas a los campos delformulario en horizontal y vertical. Estos textos son los candidatos a etiquetas.Se generan cuatro candidatos posibles como mucho. Si los textos superan unumbral de palabras (seis es la configuración por defecto) son ignorados. Porúltimo, si existen candidatos a la izquierda o encima del campo se eliminanlos que están a la derecha o debajo. Si aún existen dos candidatos, se eligeaquellos que están en negrita o en un tamaño de letra mayor que el resto. Sial final no se ha obtenido un único candidato, se toma cualquier candidato alazar.

Una vez detectadas las etiquetas de los campos, se realiza un normaliza-do de los textos encontrados usando ciertas heurísticas y técnicas de lenguajenatural, como por ejemplo, la eliminación de palabras vacías.

Las propuestas del prototipo HiWE y sobre PDAs son evaluadas haciendouso de una serie de formularios escogidos al azar. La técnica LITE obtiene unaprecisión del 93 % mientras que las técnicas textuales de PDAs tienen un 72 %de precisión y las visuales un 83 %.

Al terminar la extracción automática del modelo se pretende establecer unacorrespondencia entre las etiquetas de los campos y las entradas del reposito-rio. HiWE trabaja con un repositorio que contiene por cada entrada una eti-


F1 F2

F3

F4

F5 F6

F7 F8

F9

F10

F11

Figura 4.19: Campos del formulario de ejemplo.

queta y un conjunto de valores asociados a la etiqueta. La idea es encontraruna correspondencia entre una etiqueta del repositorio y otra de un campodel formulario. Para buscar estas correspondencias se tiene en cuenta tanto lareordenación de palabras como los errores de escritura, se emplea un algorit-mo que tiene en cuenta los dos requisitos.

4.3.4.2. Ejemplo

Aplicaremos las técnicas vistas en HiWE sobre el formulario de la Figura§B.1. En el formulario se detectan once campos que pueden verse en la Figura§4.19.

Con dichos campos se tienen las etiquetas y dominios que se ven en laFigura §4.20.

Teniendo un repositorio con las entradas author, title, publication year,price, format que normalizadas quedarían: author, titl, public year, price,format. Las etiquetas descubiertas se normalizan y quedan como: last na-me, first name, titl, format, check bargain, displai. Las etiquetas como “after”


Label(F1) = "Last Name *", Dom(F1) = s | s is a text string

Label(F2) = "First Name", Dom(F2) = s | s is a text string

Label(F3) = "Title", Dom(F3) = s | s is a text string

Label(F4) = "", Dom(F4) = “Title word(s)”,“Start(s) of title word(s)”,

“Exact start of title”

Label(F5) = "after", Dom(F5) = 2000, ..., 2009

Label(F6) = "before", Dom(F6) = 2000, ..., 2009

Label(F7) = "between US$", Dom(F7) = s | s is a text string

Label(F8) = "and US$", Dom(F8) = s | s is a text string

Label(F9) = "Format:", Dom(F9) = “Hardcover”,“Paperback”, “e-Books & Docs”

Label(F10) = "Check bargains?:", Dom(F10) = No, Yes

Label(F11) = "Display:", Dom(F11) = 10, 20

Figura 4.20: Etiquetas y valores del formulario de ejemplo.

o “between US$” desaparecen al ser palabras vacías. Se obtienen correspon-dencias para “titl” y “format”, es decir, para Title y Format.

4.3.5. Otras

Da Silva et al. [32] proponen la construcción automatizada de agentes queacceden a la hidden Web. Para la extracción de etiquetas se emplea un algorit-mo textual basado en heurísticas visuales. La heurística visual que se aplica es


que las etiquetas de los campos se suelen encontrar a la izquierda o arriba delos mismos. No existe ningún otro texto dentro del formulario que no sean lasetiquetas.

Una vez que ya se ha etiquetado el formulario, se pasa a aplicar el algo-ritmo de correspondencias. El algoritmo trata de encontrar correspondenciasentre un repositorio de datos y las etiquetas de los campos del formulario. Elrepositorio de datos empleado es un conjunto de entradas atributo, valor,por tanto, las correspondencias se establecen entre los atributos del reposito-rio y las etiquetas extraídas. Antes de pasar a analizar las correspondencias,se realiza un normalizado del repositorio de datos y de las etiquetas usandotécnicas de lenguaje natural. Las correspondencias se establecen analizandoque el conjunto de subcadenas entre etiqueta y atributo superen el 50 %.

En la evaluación del trabajo de Da Silva et al. se emplean treinta formu-larios de diez dominios distintos. En la extracción de etiquetas se logra unaprecisión y un recall de 1.0.

Kushmerick [31] presenta un algoritmo que aprende a adjuntar etiquetassemánticas a un formulario mediante aprendizaje supervisado. Como cual-quier aprendizaje supervisado, partimos de una serie de formularios etique-tados que forman nuestro conjunto de entrenamiento. Kushmerick tiene otrotrabajo similar empleando Servicios Web [25].

El objetivo del algoritmo es clasificar un formulario y sus campos de acuer-do a una taxonomía establecida a priori. Específicamente, se asumen dos ta-xonomías para adjuntar información semántica. Una taxonomía de dominio,que indica el propósito general del formulario, por ejemplo “buscar un libro”,“buscar un trabajo” o “consultar las horas de los vuelos de una aerolínea”; D= SEARCHBOOK, FINDJOB, QUERYFLIGHT, .... El otro tipo de taxonomíaes de tipo de datos, referida a la categoría semántica de un campo, por ejem-plo “título de un libro”, “sueldo” o “aeropuerto de destino”; T = BookTitle,Salary, DestAirport,....

Una vez establecidos los dominios y las taxonomías, se hace uso de unared bayesiana a tres niveles para dar semántica al formulario. Estos tres ni-veles se dividen en nivel de términos, formados por las cadenas de texto delformulario, el nivel de tipos de datos y el nivel de dominio. El resultado finaldel algoritmo es que a cada formulario se le asigna un dominio y, a cada bolsade términos dentro de dicho formulario, se le asigna un tipo de datos.

En la evaluación de la propuesta de Kushmerick se usan 129 formulariosde búsqueda y como métrica se usa la F1. Esta métrica relaciona la precisión yel recall, una medida alta de esta métrica indica que la precisión y el recall son


buenos:

F1 =2 · Recall · Precision

Recall + Precision(4.3)

Para la predicción del dominio temático de un formulario se obtiene un0.87 y para la predicción del tipo de datos un 0.43.

Gal et al. [17, 38] trabajan en la población de ontologías partiendo de pá-ginas HTML. El objetivo es automatizar el proceso de creación y adaptaciónde ontologías. Una ontología inicial es creada usando tanto herramientas deextracción como una ya existente. Una vez creada, el usuario realiza una se-sión de búsqueda de información donde se va refinando la ontología con loelegido por el usuario. Este proceso es iterativo. Gal et al. obtienen un modelode formulario expresado como una ontología.

La estructura de la ontología objetivo posee: Términos consistentes en unconjunto formado por un campo y la etiqueta que lo designa, los posibles Va-lores que toman los términos, Composiciones que son agrupaciones que lostérminos pueden formar y, Precedencias donde se establece un orden al serrellenado el formulario.

El tener en cuenta la precedencia en el rellenado de formularios es unaaportación muy importante que hace este trabajo, a nuestro entender. Ningu-na propuesta tiene en cuenta que puede establecerse un orden entre campos ala hora de rellenar un formulario con una consulta. La precedencia se obtienede manera automática analizando en los distintos formularios el orden de pre-sentación de cada campo. Por ejemplo, en el formulario de la Figura §B.1, LastName es anterior a First Name al estar arriba y a la izquierda que, visualmente,es anterior a arriba y a la derecha.

La extracción de campos y etiquetas se realiza empleando una serie deheurísticas sobre el árbol DOM del formulario de búsqueda. Las heurísticasconsisten en una serie de patrones que se repiten en todos los formularios yson aplicados en la extracción. Por cada campo del formulario, se extrae sunombre interno, etiqueta, tipo (si es una lista de selección, un radio u otros) yel conjunto de valores presentados en una lista de selección o campos radio ocheckbox.

En la fase de adaptación, el usuario propone una serie de aplicaciones Webdel mismo dominio que el formulario procesado para refinar la ontología crea-da. Sobre cada aplicación seleccionada se vuelve a aplicar el proceso de extrac-ción y una nueva ontología es creada, esta ontología es una ontología candi-data. La ontología original es la ontología objetivo. Tanto la objetivo como lacandidata son combinadas para refinar y generalizar la ontología existente. La


combinación se hace estableciendo correspondencias entre los términos de lasdos ontologías empleando técnicas de lenguaje natural y heurísticas como eli-minar caracteres que pueden ser ignorados, eliminación de palabras vacías ocomparación de cadenas. Los términos para los que no se encuentran corres-pondencias son rechazados.

Freie et al. [39] propone la extracción de etiquetas de un formulario me-diante un clasificador que aprende a generar asociaciones entre etiquetas ycampos. Además, se aplica una reconciliación de asociaciones que permite au-mentar la precisión de la extracción. La propuesta se llama LabelEx de LabelExtraction.

LabelEx opera en dos fases que consisten en el entrenamiento de los cla-sificadores y la extracción de etiquetas. Internamente la propuesta cuenta conun clasificador bayesiano y un árbol de decisión. Durante la fase de entrena-miento se generan una serie de asociaciones entre campos y etiquetas y, ma-nualmente, se decide si son correctas o no. Esta información se emplea paraentrenar el clasificador bayesiano, la salida obtenida del primer clasificador esempleada para entrenar el árbol de decisión. El clasificador bayesiano se usapara podar las asociaciones incorrectas y el árbol de decisión para seleccionarlas correctas.

Durante la fase de extracción de etiquetas se generan las asociaciones can-didatas, se eliminan las asociaciones incorrectas mediante la acción del primerclasificador y se eligen las correctas usando el segundo clasificador. Las eti-quetas extraídas se almacenan en un repositorio interno. Por último, la recon-ciliación de asociaciones hace uso del repositorio de etiquetas para elegir lamejor etiqueta de aquellos campos a los que se le ha asignado más de una oninguna.

LabelEx ha sido probado con dos conjuntos de datos distintos, el prime-ro de ellos son 2884 formularios de búsqueda recolectados por Form-FocusedCrawler (FFC) [3]. FFC consiste en un crawler que encuentra formularios dela hidden Web de un dominio temático determinado. El segundo conjunto dedatos es TEL-8 de UIUC. Se emplea la métrica F1 (§4.3) para realizar las eva-luaciones resultando 0.93 y 0.95 en FFC y TEL-8 respectivamente en el dominiode venta de libros. En el dominio de venta de películas se obtiene 0.86 y 0.90para ambos conjuntos de datos.

LabelEx es comparada con las propuestas de Chang et al. [56] y Meng etal. [23]. En la Figura §4.21 [39] la propuesta de Meng et al. es identificada co-mo IEXP, Chang et al. como HSP y la de Freire et al. es dividida en dos, unaen donde no se tiene en cuenta el dominio (Generic Classifier + MR, GMR) yotra en la que sí se tiene en cuenta (Domain-specific Classifier + MR, DSMR).


Figura 4.21: Comparativa entre Freire et al., Chang et al. y Meng et al..

DSMR se construye entrenando cuatro clasificadores distintos, uno por cadadominio temático. Los peores resultados son los obtenidos por IEXP y los me-jores por DSMR.

4.4. Framework de comparación

Una vez presentadas todas las propuestas relativas al modelado de for-mularios, hacemos una comparativa entre las distintas propuestas estudiadasanalizando las características comunes más relevantes. No todas las propues-tas tratan todos los problemas asociados al modelado de formularios que sehan presentado en el apartado §4.2. La comparativa resultante puede verse enlas Tablas §4.1 y §4.2 donde las propuestas estudiadas corresponden a Changet al., Meng et al., Álvarez et al., Garcia-Molina et al., Da Silva et al., Kush-merick, Gal et al. y Freire et al.; las características estudiadas en estas tablasson:

L: ¿Extrae etiquetas de manera automática?

Md: ¿Extrae los campos obligatorios del formulario de manera automá-tica?

Or: ¿Tiene en cuenta el orden de rellenado del formulario?

At: ¿Identifica los atributos del formulario?

Fg: ¿Tiene en cuenta agrupaciones de campos y etiquetas que formenatributos?


DC: ¿Distingue entre campos de dominio y restricción?

Tr: ¿Descubre relaciones entre campos de tipo rango?

Tp: ¿Descubre relaciones entre campos de tipo parte?

Tg: ¿Descubre relaciones entre campos de tipo grupo?

ADD: ¿Tiene en cuenta que los atributos pueden ser de dominio o pre-sentación?

Vt: ¿Detecta el tipo de valor de un atributo?

U: ¿Detecta la unidad del valor de un atributo?

Lr: ¿Es capaz de establecer las relaciones lógicas que se dan entre atribu-tos al realizar consultas sobre la base de datos oculta?

Sm: ¿Establece correspondencias semánticas entre campos y atributos?

Fv: ¿Tiene en cuenta los valores de los campos en el procesamiento?

Qc: ¿Extrae la capacidad de consulta?

Mf: ¿Se hace efectivo el modelo con algún tipo de formalismo?

Cs: ¿Tiene en cuenta sólo el lado cliente?

DR: ¿Hace uso de un repositorio interno de datos?

Qm: ¿Acepta el modelo consultas expresadas en algún lenguaje de altonivel?

4.5. Conclusiones

Una vez estudiadas las diferentes propuestas existentes en la bibliografíaobservamos que, mientras que algunos problemas están resueltos y muy es-tudiados, existen ciertos problemas que están poco o nada tratados. Ademásde los problemas, también se analizan los resultados de los distintos ejemplosestudiados para cada propuesta.

Los problemas más estudiados son la extracción automática de etiquetas(todos los trabajos estudiados tratan este tema a excepción de Kushmerick[31]), la identificación de atributos y el establecimiento de correspondencias


L Md Or At Fg DC Tr Tp Tg ADD

Chang Sí No No Sí Sí Sí Sí Sí Sí No

Meng Sí Sí No Sí Sí Sí Sí Sí Sí No

Álv. Sí No No Sí No No No No Sí No

G.-M. Sí No No Sí No No No No Sí No

Da S. Sí No No Sí No No No No No No

Kush. No No No Sí No No No No No No

Gal Sí No Sí Sí Sí No No Sí No No

Freire Sí No No No No No No Sí No No

Tabla 4.1: Comparativa de propuestas de modelado de formularios (1).

Vt U Lr Sm Fv Qc Mf Cs DR Qm

Chang No No No Sí Sí Sí No Sí No No

Meng Sí Sí Sí Sí Sí Sí Sí No No No

Álv. No No No Sí Sí No No Sí Sí No

G.-M. No No No Sí Sí No Sí No Sí No

D. S. No No No Sí Sí No No Sí Sí No

Kush. No No No Sí Sí No No Sí Sí No

Gal No No No Sí Sí No Sí Sí Sí No

Freire No No No No Sí No No Sí Sí No

Tabla 4.2: Comparativa de propuestas de modelado de formularios (2).

semánticas (todos los trabajos estudiados los tratan a excepción de Freire et al.[39]).

Un problema poco estudiado es la detección automática de campos obliga-torios (Md), que sólo es tratada en [52], cuando creemos que es un problemafundamental. Si no se tiene conocimiento de qué campos son obligatorios, lasconsultas realizadas al formulario fallarán. Este problema está muy relaciona-do con la viabilidad de una consulta sobre un formulario: si no se especificanlos campos obligatorios exigidos, la consulta no se podrá realizar.


Otro problema importante poco estudiado es el descubrimiento de las re-laciones lógicas entre atributos cuando se consulta la base de datos oculta porun formulario de búsqueda (Lr). En este caso, [23] incluye en su modelo for-mal la capacidad para representar estas relaciones. Distingue cuatro tipos derelaciones lógicas: exclusivas, conjuntivas, disyuntivas e híbridas.

Las exclusivas son resueltas mediante el estudio de varios formularios debúsqueda del mismo dominio temático y analizando cuál es el vocabulario co-mún predominante. Aquellos campos cuya etiqueta pertenezca al vocabulariocomún predominante, serán campos exclusivos. Para las relaciones conjunti-vas, disyuntivas e híbridas se afirma que, al realizar consultas sobre el formu-lario con distintos campos rellenos, se puede averiguar qué relaciones existen.Sin embargo, la formulación automática de consultas sobre los formularios escompleja y se presupone que, si no existe ningún campo haciendo referenciaa relaciones lógicas (tipo AND u OR), la relación lógica entre atributos es detipo AND, es decir, conjuntiva.

Otro problema poco estudiado es la identificación de orden en el rellenadode formularios de búsqueda (Or). Gal et al. [17, 38] soporta en su modelo elorden entre campos y se identifica de manera automática mediante la inter-pretación visual de los campos del formulario. Es decir, si un campo aparecearriba a la izquierda se deberá rellenar primero que un campo arriba a la de-recha. Sin embargo, no existe ninguna evaluación empírica que demuestre laprecisión de esta técnica.

Un problema no resuelto es la identificación automática del tipo de un atri-buto (Vt). En [52] se hace una distinción entre los tipos de atributos que pue-den existir, aquellos que realmente consultan a la base de datos oculta y losque son utilizados para modificar los resultados mostrados al recibir la res-puesta del servidor. Se apunta a que, para resolver éste problema, se puedeutilizar las técnicas vistas en el tema de correspondencias semánticas pero nose explica en detalle cómo abordarlo.

Otro problema no resuelto es aceptar consultas expresadas en lenguajes dealto nivel para los formularios modelados (Qm). Las propuestas de tipo me-tasearch unifican todos los formularios en un único formulario que el usuariopuede rellenar. En este tipo de propuestas, las consultas del usuario se reflejanen el sistema como el rellenado del formulario unificado. Las propuestas detipo crawling no permiten las consultas de usuario.

Los diferentes ejemplos estudiados en las propuestas ofrecen resultadosinteresantes. Las propuestas de Chang et al. y Meng et al. ofrecen buenos re-sultados en los ejemplos estudiados. Sin embargo, la propuesta de Álvarez etal. no reconoce el formulario de ejemplo (ver Figura §B.1) como perteneciente


al dominio de venta de libros y lo descarta. Esto es debido a que la propuestano es capaz de reconocer relaciones de tipo rango y parte, por tanto, no reco-noce Author o Publication Year. Únicamente reconoce Title y Format perono son suficientes para aceptar el formulario como relevante. La propuesta deGarcia-Molina et al. tiene el mismo problema y sólo reconoce Title y Format.

Para terminar y a modo de resumen, ofrecemos una clasificación de losproblemas poco estudiados y los no resueltos. La resolución de estos proble-mas abre nuevas vías de investigación:

Problemas poco estudiados

Detección automática de campos obligatorios (Md)

Descubrimiento de relaciones lógicas entre atributos (Lr)

Problemas no resueltos

Identificación de orden en el rellenado de formularios (Or)

Identificación automática del tipo de un atributo (Vt)

Aceptar consultas expresadas en lenguajes de alto nivel (Qm)

Capítulo 5

Lenguajes de consulta

Enhance 224 to 176. Enhance, stop. Move in, stop. Pull out, track right, stop. [...] Give me ahard copy right there.

Deckard uses the Esper machine, Blade Runner, 1982

E n este capítulo damos un repaso a los diferentes lenguajes de consultaexistentes para la Web semántica, en concreto, para la consulta de

grafos RDF. Los lenguajes que estudiamos son RQL, RDQL, SeRQL, SPARQLy una breve reseña de otros.

86 Capítulo 5. Lenguajes de consulta

SELECT lastname, firstnameFROM AuthorWHERE

lastname = ’Dick’

Figura 5.1: Ejemplo de consulta SQL.

5.1. Introducción

El lenguaje de alto nivel más conocido es el SQL (Structured Query Lan-guage). SQL es un lenguaje declarativo de acceso a bases de datos relacionales.Un ejemplo de consulta escrita en SQL puede verse en la Figura §5.1, dondese solicita el apellido y nombre de autores con apellido ‘Dick’. SQL está muyligado a las bases de datos relacionales y no tiene ninguna relación con la Web.

El contenido de la Web está pensado para usuarios y no para programas.La Web actual está construida mezclando la información (los datos) y la pre-sentación (código fuente HTML). Separando la información y la presentaciónse podría dar semántica a la información contenida en cualquier página [6]:“The Semantic Web is not a separate Web but an extension of the current one,in which information is given well-defined meaning, better enabling compu-ters and people to work in cooperation”.

Las bases de datos relacionales y el SQL no están pensados para la Web, sinembargo, la Web semántica parece el escenario ideal. RDF (Resource Descrip-tion Framework) es un lenguaje de propósito general para representar infor-mación en la Web. En lo que resta de capítulo estudiamos el modelo RDF y ellenguaje de consulta de alto nivel SPARQL, que permite extraer la informacióncodificada en RDF.

5.2. RDF

RDF (Resource Description Framework) es un modelo de datos con formade grafo [2]. Los conceptos básicos de RDF son los recursos, las propiedades ylas declaraciones. Los recursos son objetos como autores, libros o editoriales.Todo recurso posee una URI (Universal Resource Identifier) que lo identificaunívocamente. Las propiedades describen relaciones entre recursos y también

5.2. RDF 87

www.booksexample.com/book Blade RunnerhasTitle

www.booksexample.com/book-authorisWrittenBy

Philip

K. Dick hasLastName

hasFirstName

Figura 5.2: Ejemplo de grafo RDF.

(http://www.booksexample.com/book,http://www.booksexample.com/hasTitle,

"Blade Runner")

(http://www.booksexample.com/book,http://www.booksexample.com/isWrittenBy,

http://www.booksexample.com/book-author)

(http://www.booksexample.com/book-author,http://www.booksexample.com/hasFirstName,

"Philip K.")

(http://www.booksexample.com/book-author,http://www.booksexample.com/hasLastName,

"Dick")

Figura 5.3: Tripletas RDF.

son identificadas mediante URIs. Por último, las declaraciones son tripletasobjeto-atributo-valor consistentes en un recurso, una propiedad y un valor.

Un ejemplo de grafo RDF puede verse en la Figura §5.2, en este grafo seexpresa que un libro tiene un título y un autor. Las tripletas que origina estegrafo pueden verse en la Figura §5.3 expresadas como (recurso, propiedad,valor), también conocido como (sujeto, predicado, objeto).

Los grafos son potentes herramientas para un usuario pero la Web semán-


Book

Author

isWrittenBydomain

range

Person subClassOf

hasTitledomain Literalrange

hasFirstName

domain

range

hasLastNamedomain

range

www.booksexample.com/book Blade RunnerhasTitle

www.booksexample.com/book-authorisWrittenBy

Philip

K. Dick hasLastName

hasFirstName

RDFS

RDF

Figura 5.4: Ejemplo de RDFS y su relación con RDF.

tica requiere representaciones accesibles y procesables por ordenadores. Estarepresentación se realiza mediante XML, un documento RDF comienza conuna etiqueta rdf:RDF y tiene una sintaxis concreta [4].

RDF es un lenguaje universal que permite al usuario modelar los datosusando su propio vocabulario, no tiene incorporado conocimiento de ningúndominio temático en particular. RDF Schema (RDFS) sirve para que los usua-rios puedan definir la semántica de un dominio, expresado de otra forma,RDFS es el lenguaje básico para expresar ontologías. Los dominios se des-criben usando clases y propiedades, las clases definen tipos de objetos y laspropiedades imponen restricciones sobre los datos. Un ejemplo de RDFS y có-mo se relaciona con RDF puede verse en la Figura §5.4, las propiedades estánexpresadas como rectángulos y las clases como elipses.

Antes de entrar a estudiar los distintos lenguajes de consulta de alto nivelpropuestos para RDF (para la Web semántica), vamos a justificar por qué esnecesario un lenguaje de consulta específico. Si RDF se codifica como XML,¿por qué no usar un lenguaje de consulta XML en lugar de uno nuevo? Larespuesta es que XML tiene menos nivel de abstracción que RDF y puede ge-nerar complicaciones si se consulta RDF con un lenguaje de consulta XML. Larazón es que RDF puede representarse en XML de varias maneras distintas

5.3. RQL 89

y, al consultar XML con Xpath, se hace necesario modificar las consultas paracada representación. La mejor manera de realizar consultas es a nivel de RDF.

Un lenguaje de consulta apropiado debe entender RDF, es decir, debe en-tender no sólo la sintaxis sino también el modelo de datos de RDF y la semán-tica del vocabulario RDF. Así mismo, un lenguaje de consulta debe entenderla semántica de RDF Schema.

5.3. RQL

RQL es un lenguaje de consulta válido tanto para RDF como para RDFS. Susintaxis es parecida a la de OQL (Object Query Language, lenguaje de consultaestándar de bases de datos orientadas a objetos). La idea básica de RQL esofrecer una vista de los modelos y esquemas de RDF como si de un grafoconexo se tratase. RQL ofrece la posibilidad de navegar sobre dicho grafo yseleccionar tanto nodos como artistas [7].

Una de las características principales de RQL es que permite consulta lasemántica de RDFS. Las relaciones entre clases, entre clases y propiedades o dedominio/rango pueden ser consultadas mediante construcciones específicasdel lenguaje.

Las consultas básicas permiten extraer las clases y las propiedades. Pue-den verse algunos ejemplos de consultas básicas en la Figura §5.5. La primeraconsulta extrae todas las instancias de la clase Author y todas las instancias desus subclases. La segunda consulta extrae únicamente las instancias de la cla-se Author si las instancias de las subclases no son de nuestro interés. Cuandose consulta una propiedad se obtiene como resultado los recursos y valoresde las tripletas RDF de dicha propiedad, la tercera consulta obtiene todas lastripletas RDF de la propiedad isWrittenBy y sus subpropiedades. La cuartaconsulta no extrae las subpropiedades de isWrittenBy.

RQL también admite consultas más complejas que se expresan de manerasimilar a SQL, es decir, con select-from-where. Con select se especifica el nú-mero y orden de los datos extraídos, from es usado para navegar por el modelode datos y where restringe los resultados. Pueden verse algunas consultas deejemplo en la Figura §5.6, en la primera se obtienen todos los recursos y va-lores de las tripletas con propiedad hasLastName. En la segunda consulta seobtienen los autores y sus apellidos, por último, en la tercera se obtienen losautores cuyos apellidos coincidan con “Dick”.

RQL también permite la posibilidad de realizar consultas y extraer el es-


1.- Author

2.- ^Author

3.- isWrittenBy

4.- ^isWrittenBy

Figura 5.5: Ejemplo de consultas básicas RQL.

1.- select X, Yfrom XhasLastNameY

2.- select X, Yfrom authorX.hasLastNameY

3.- select X, Yfrom authorX.hasLastNameYwhere Y = "Dick"

Figura 5.6: Ejemplo de consultas RQL tipo SQL.

quema RDF. Las variables que se emplean para consultar el esquema tienencomo prefijo $ para las clases y @ para las propiedades. En la Figura §5.7 se vendos ejemplos de consultas sobre el esquema RDF, la primera obtiene los recur-sos, las clases de estos recursos, los valores y las clases de los valores para losque existe alguna tripleta con propiedad hasLastName. La segunda consultaextrae el dominio y rango de la propiedad hasFirstName.

Existe una implementación de RQL disponible en la página http://139.91.183.30:9090/RDF/RQL/. La versión 2.1 está implementada en C++ y hace usode PostgreSQL (gestor de base de datos relacional).

http://139.91.183.30:9090/RDF/RQL/

http://139.91.183.30:9090/RDF/RQL/

5.4. RDQL 91

1.- select X, $X, Y, $Yfrom X:$XhasLastNameY:$Y

2.- select domain(@FN), range(@FN)from @FNwhere @FN = hasFirstName

Figura 5.7: Ejemplo de consultas RQL sobre esquema.

5.4. RDQL

RDQL (RDF Data Query Language) es un lenguaje de consulta propuestopor Hewlett-Packard. El 9 de enero de 2004 se presentó al W3C para su dis-cusión [51]. RDQL está implementado en algunos sistemas con el objetivo deextraer información del grafo RDF. RDQL consiste en patrones de grafos ex-presado como una lista de patrones de tripletas. Cada patrón de tripleta estácompuesto por variables y valores RDF (URIs y literales). Una consulta RDQLpuede contener un conjunto de restricciones sobre los valores de las variables.

Algunos ejemplos de consultas en RDQL pueden verse en la Figura §5.8,en la primera consulta se consultan todos los libros existentes. En la segundaconsulta, se extrae el autor, libro y título donde el autor es Philip K. Dick.

No existe una implementación de RDQL, pero los frameworks menciona-dos a continuación tienen algún tipo de tratamiento con patrones de tripletasy restricciones, que puede ser descrito como RDQL. Los frameworks son Jena(Java), RDFStore (Perl), Sesame (Java) y PHP XML Classes (PHP).

5.5. SeRQL

SeRQL (Sesame RDF Query Language) está desarrollado por Aduna Soft-ware como parte de Sesame (http://www.openrdf.org/). Combina característicasde otros lenguajes de consulta (como RQL o RDQL) y añade algunas nuevas.SeRQL soporta dos tipos de consultas, aquellas que devuelven datos y las queobtienen un grafo RDF como respuesta [8]. Por simplicidad se dará una brevevisión de las que devuelven datos, es decir, de las consultas tipo select.

http://www.openrdf.org/


1.- SELECT ?xWHERE (?x,

<http://www.booksexample.com/isWrittenBy,<http://www.booksexample.com/book-author>)

2.- SELECT ?author, ?book, ?titleWHERE (?author booksample:hasFirstName "Philip

K.")(?author booksample:hasLastName "Dick")(?book booksample:isWrittenBy ?author)(?book booksample:hasTitle ?title)

USING booksample FOR <http://www.booksexample.com/>

Figura 5.8: Ejemplo de consultas RDQL.

1.- SELECT Book, AuthorFROM Book ex:isWrittenBy Author ex:hasLastName LastNameWHERE LastName LIKE "*Dick"USING NAMESPACE

ex = <http://www.booksexample.com/>

Figura 5.9: Ejemplo de consulta SeRQL.

Las consultas de datos tienen la forma típica de SQL con select, from ywhere. Con la cláusula select se especifica qué variable se va a consultar y enqué orden. La cláusula from es opcional y se emplea para expresar patronesde rutas en el grafo RDF. La cláusula where también es opcional y se empleapara especificar restricciones lógicas sobre los datos extraídos.

Un ejemplo de consulta en SeRQL puede verse en la Figura §5.9, donde seextraen los libros y autores cuyo apellido del autor termine en Dick. SeRQLestá implementado únicamente en Sesame.

5.6. SPARQL 93

1.- PREFIX bs: <http://www.booksexample.com/>SELECT ?author ?titleWHERE

?book bs:hasTitle ?title .?book bs:isWrittenBy ?author

Figura 5.10: Ejemplo de consulta simple SPARQL.

5.6. SPARQL

SPARQL (SPARQL Protocol and RDF Query Language) es una recomenda-ción del W3C desde enero de 2008. SPARQL permite consultar RDF haciendouso de patrones de grafos empleando conjunciones y disyunciones. Los resul-tados de las consultas formuladas con SPARQL pueden ser conjuntos de datoso grafos RDF [44].

Las consultas generadas con SPARQL poseen patrones de tripletas. Estospatrones son similares a las tripletas RDF salvo que el sujeto, predicado u ob-jeto pueden ser variables. Un ejemplo de consulta simple puede verse en laFigura §5.10, donde se consulta el autor y el título de todos los libros almace-nados.

Se pueden escribir otras consultas más complejas como las que se ven en laFigura §5.11. En la primera consulta se buscan los nombres y apellidos de au-tores cuyo apellido sea “Dick”. La segunda consulta encuentra los nombres yapellidos de autores que tengan o no libros registrados. La condición opcionalexpresa que, si un autor no tiene libros registrados, se obtenga únicamente sunombre y apellidos.

Existen varios frameworks que implementan SPARQL. Un informedesarrollado por el W3C estudia, de cada framework, qué característicasde SPARQL tiene implementadas y cuáles no (http://www.w3.org/2001/sw/DataAccess/impl-report-ql). Algunos de los frameworks que implementanSPARQL son ARQ (que forma parte de Jena), Sesame o Virtuoso.

http://www.w3.org/2001/sw/DataAccess/impl-report-ql

http://www.w3.org/2001/sw/DataAccess/impl-report-ql


1.- PREFIX bs: <http://www.booksexample.com/>SELECT ?firstName ?lastNameWHERE

?author bs:hasFirstName ?firstName .?author bs:hasLastName ?lastName .FILTER regex(?lastName, "Dick")

2.- PREFIX bs: <http://www.booksexample.com/>SELECT ?firstName ?lastName ?bookWHERE

?author bs:hasFirstName ?firstName .?author bs:hasLastName ?lastName .OPTIONAL ?book bs:isWrittenBy ?author

Figura 5.11: Ejemplo de consulta complejas SPARQL.

5.7. Otros lenguajes

Existen multitud de lenguajes de consulta a RDF, en [43] se presenta unsurvey con los diferentes lenguajes y sus implementaciones. Además, se estu-dian una serie de características comunes a todos los lenguajes estableciendodiferentes comparativas.

Algunos de estos lenguajes de consulta son Algae2, Squish o TRIPLE. Sinembargo, creemos que hemos presentado los más importantes y no entrare-mos en detalle sobre estos.


Una vez analizados varios lenguajes de consulta RDF establecemos un fra-mework de comparación entre ellos. En la Tabla §5.1 puede verse la compara-


PE OPE DT Cl AF S W3C

RQL Sí - Sí No Sí No No

RDQL Sí No - No No No No

SeRQL Sí Sí Sí Sí No No No

SPARQL Sí Sí Sí Sí No Sí Sí

Tabla 5.1: Comparativa de lenguajes de consulta RDF.

tiva donde las características estudiadas son:

PE: ¿Permite expresar caminos que recorran el grafo RDF?

OPE: ¿Permite expresar caminos opcionales en el grafo RDF?

DT: ¿Permite la consulta de distintos tipos de datos?

Cl: ¿Los resultados de una operación son, de nuevo, elementos del mo-delo de datos?

AF: ¿Permite el uso de funciones de agregación? (tipo COUNT de SQL,por ejemplo)

S: ¿Permite la ordenación de resultados?

W3C: ¿Está recomendado por el W3C?

Los valores que toma dicha comparativa pueden ser que sí se soporta lacaracterística estudiada, no se soporta o se soporta parcialmente (-). Muchosde estos datos han sido extraídos de [18], donde se presenta una comparativacon los distintos lenguajes de consulta RDF, excluyendo SPARQL.

5.9. Conclusiones

Existen multitud de lenguajes de consulta para RDF implementados enmultitud de frameworks. Como hemos visto en la Tabla comparativa §5.1, nin-gún lenguaje de consulta soporta todas las características estudiadas. Sin em-bargo, una característica destaca por encima de todas: la recomendación del


W3C. SPARQL es el que destaca por encima del resto al estar aprobado comorecomendación por el W3C.

La única característica no soportada por este lenguaje es el uso de funcio-nes de agregación (como COUNT, MIN o MAX de SQL). En la recomendaciónhan quedado doce cuestiones pospuestas para futuras revisiones, entre ellas,el uso de funciones de agregación. Por tanto, es posible que en un futuro seincluyan. En la actualidad existen algunas implementaciones que soportan eluso de este tipo de funciones, por ejemplo, Virtuoso.

Capítulo 6

Herramientas para el rellenado y lanavegación

I’m not talkin’ ’bout pleasure boatin’ or day sailin’. I’m talkin’ ’bout workin’ for a livin’. I’mtalkin’ ’bout sharkin’!

Quint, Jaws, 1975

E n este capítulo estudiamos las diferentes propuestas comerciales exis-tentes que se pueden emplear para rellenar formularios o realizar na-

vegaciones por distintas aplicaciones Web. Estudiamos en profundidad algu-nas de ellas como Watij, Selenium o iMacros dando un ejemplo aclaratoriode cada una. Por último, presentamos una comparativa de las distintas herra-mientas estudiadas.

98 Capítulo 6. Herramientas para el rellenado y la navegación

6.1. Introducción

Existen multitud de herramientas comerciales que pueden ser usadas pararellenar formularios automáticamente y realizar navegaciones por aplicacio-nes Web. La finalidad de estas herramientas no es el propio rellenado o nave-gación sino el Web testing, es decir, el desarrollo de tests que permitan ejecutarpruebas sobre aplicaciones Web de forma automática y metódica.

El Web testing se usa con objetivos principales: el test de requisitos y stress.El test de requisitos está relacionado con el lado cliente, en este tipo de testsse comprueba la funcionalidad de la aplicación de cara al usuario. Los testde stress están más relacionados con el lado de la aplicación, consisten en si-mular interacciones masivas de usuario para evaluar la escalabilidad de unaaplicación Web.

Las mismas herramientas de Web testing pueden emplearse en el rellena-do de formularios y navegación automática por aplicaciones Web. Estas he-rramientas soportan, en conjunto, casi todos los navegadores existentes. Elabanico de lenguajes de programación que emplean es también amplio, conlenguajes como Java, Python, Ruby, C++ o C#. Dan soporte para tecnologíaSSL, Applets, Flash, ActiveX, AJAX o Silverlight.

A continuación estudiamos un ejemplo de rellenado y navegación que seaplica a cada herramienta estudiada. De esta forma, proporcionamos el mismoejemplo explicativo de cada una.

6.2. Ejemplo

Para comprender mejor cada herramienta, proporcionamos un ejemplo ba-sándonos en el formulario que venimos usando en todo el documento. Esteformulario de ejemplo puede verse en la Figura §B.1. El ejemplo consiste enrellenar el único campo requerido por el formulario, que en este caso es elapellido de un autor (Last Name) y realizar un envío del formulario a la apli-cación simulando un click sobre el botón “Search Books!”. Usaremos “Dick”como apellido de ejemplo.

El ejemplo que se proporciona de cada herramienta depende del interfazde la misma. Algunas herramientas ejecutan tests escritos en lenguajes de pro-gramación y se proporciona el código fuente necesario para llevar a cabo elrellenado y el envío. Otras herramientas permiten especificar las acciones me-diante una interfaz gráfica y, en estos casos, el ejemplo consiste en capturas de

6.3. Watir, Watij y Watin 99

pantalla de la interfaz.

6.3. Watir, Watij y Watin

Watir (http://wtr.rubyforge.org/) es una librería de código abierto para au-tomatizar las navegaciones por la Web. Sus siglas son Web Application Tes-ting In Ruby. Permite escribir tests que son sencillos de entender y mantener.Permite simular interacciones de usuario pulsando sobre enlaces, rellenandoformularios o presionando botones. También sirve para comprobar los resul-tados de los tests, comprobando la existencia de un texto en una página, porejemplo.

Soporta Internet Explorer, Firefox gracias a FireWatir y Safari gracias a Sa-fariWatir. Su código fuente está escrito en Ruby que permite conexiones a ba-ses de datos, leer ficheros de datos y exportar a XML. Además, a diferencia deotros lenguajes de programación, Ruby es conciso y fácil de leer.

El código fuente del ejemplo puede verse en la Figura §6.1. En la línea 2se carga Watir para poder comenzar a trabajar, una vez cargado, se indica laaplicación Web a visitar en la línea 5. En la línea 8 se ejecuta el navegador,en este caso Internet Explorer, y en la línea 14 se navega hasta la direcciónindicada en la línea 5. Una vez abierta la página en el navegador, se rellena elcampo con el valor deseado, en este caso, el campo se llama ‘author_last’ (línea17). Un vez relleno el campo se pulsa el botón con nombre ‘sbooks’ (línea 21)para realizar el envío del formulario a la aplicación.

Watij (http://www.watij.com/) es una API 100 % Java basada en Watir. Sussiglas significan Web Application Testing In Java. Sirve para automatizar lostests sobre aplicaciones Web. Su uso se restringe a Internet Explorer pero setiene planificado dar soporte a Firefox.

Gracias a Java se tiene acceso a innumerables herramientas y librerías yadesarrolladas y probadas para este lenguaje de programación. Esto se traduceen que en los tests desarrollados no sólo se restringen a probar aplicacionesWeb, es posible realizar llamadas a servicios Web, conexiones a bases de datoso lectura de ficheros; en general, todo lo que permita Java y sus herramientasy librerías.

El código fuente del ejemplo puede verse en la Figura §6.2. En las líneas 1y 2 se importan las clases pertenecientes a Watij. En las líneas 4 y 5, se declarauna clase que contendrá un método que realiza el test. En la línea 6 se ejecutael navegador, en este caso Internet Explorer, y se navega hasta la dirección

http://wtr.rubyforge.org/

http://www.watij.com/


1 # the Watir controller2 require "watir"34 # set a variable5 test_site = "http://www.booksexample.com"67 # open the IE browser8 ie = Watir::IE.new910 # print some comments11 puts "Beginning of test: Last Name filling..."1213 puts " Step 1: go to the test site: " + test_site14 ie.goto test_site1516 puts " Step 2: enter ’Dick’ in the Last Name text field."17 ie.text_field(:name, "author_last").set "Dick"18 # "author_last" is the name of the search field1920 puts " Step 3: click the ’Search Books!’ button."21 ie.button(:name, "sbooks").click22 # "sbooks" is the name of the Search button

Figura 6.1: Ejemplo de rellenado de formularios con Watir.

indicada en la barra de direcciones (línea 7). Una vez cargado el formularioen el navegador, se rellena el campo ‘author_last’ con el valor a buscar (línea8). Una vez relleno el campo, se pulsa el botón que tiene como valor ‘SearchBooks!’ (línea 9) para realizar el envío del formulario al servidor.

Watin (http://watin.sourceforge.net/) (Web Application Testing In .Net) esuna herramienta escrita en C# para realizar tests sobre aplicaciones Web en.Net. Soporta Internet Explorer y Firefox.

El código fuente del ejemplo puede verse en la Figura §6.3. En las líneas 1y 2 se declara el test. En la línea 4 se ejecuta un nuevo navegador, en este casoInternet Explorer, y se navega hasta la dirección indicada en la barra de di-

http://watin.sourceforge.net/

6.3. Watir, Watij y Watin 101

1 import junit.framework.TestCase;2 import static watij.finders.SymbolFactory.*;34 public class BooksExampleTest extends TestCase 5 public void testBooksSearch() throws Exception 6 IE ie = new IE();7 ie.start("http://www.booksexample.com");8 ie.textField(name,"author_last").set("Dick");9 ie.button("Search Books!").click();10 11

Figura 6.2: Ejemplo de rellenado de formularios con Watij.

1 [Test]2 public void SearchForBooks()3 4 using (IE ie = new IE("http://www.booksexample.com"))5 6 ie.TextField(Find.ByName("author_last"))7 .TypeText("Dick");8 ie.Button(Find.ByName("sbooks")).Click();9 10

Figura 6.3: Ejemplo de rellenado de formularios con Watin.

recciones. Una vez cargado el formulario en el navegador, se rellena el campo‘author_last’ con el valor oportuno (líneas 6 y 7). Una vez relleno el campo, sepulsa el botón que tiene como nombre ‘sbooks’ (línea 8) para realizar el envíodel formulario al servidor.


6.4. Selenium

Selenium (http://selenium.openqa.org/) es una herramienta para realizartests de aplicaciones Web. Los tests que se ejecutan con Selenium corren di-rectamente sobre un navegador, exactamente igual que haría un usuario. Se-lenium tiene soporte para Internet Explorer, Mozilla y Firefox en entornosWindows, Linux y Macintosh. También soporta Safari únicamente en entor-nos Mac. Selenium está dividido en cuatro módulos que son Selenium IDEconsistente en un plugin para Firefox que permite escribir test completos, Se-lenium Core incorpora las librerías básicas de Javascript para que los tests seancargados dentro de la aplicación Web, Selenium Remote Control despliega ser-vidores remotos de tests y, Selenium Grid permite que los servidores remotosde Remote Control puedan ser accedidos en paralelo por más de un proceso ala vez.

Para comprobar la potencia y estudiar si Selenium es la mejor herramien-ta posible para desarrollar tests en algún proyecto, la mejor forma es utilizarSelenium IDE. Un ejemplo de test empleando Selenium IDE puede verse en laFigura §6.4. Se han declarado tres comandos, el primero de ellos hace que senavegue hasta la página principal de la URL base (se obtendrá como respues-ta el formulario de ejemplo), en el segundo comando se rellena el apellido delautor con el valor deseado y, por último, se simula un click sobre el botón debúsqueda.

6.5. HTTPUnit

Los tests automáticos son una buena manera de asegurar que el código queestá siendo mantenido funciona. La metodología Extreme Programming (XP)depende de estos tests y muchas de las herramientas recomendadas (http://www.xprogramming.com/software.htm) funcionan mediante llamadas directasal código fuente, ¿qué ocurre si lo que se desea probar es una aplicación Web?

En este tipo de casos es necesario acceder a la aplicación Web simulandoun navegador, para ello, HTTPUnit (http://httpunit.sourceforge.net) permite laejecución de pruebas en entornos Web. Puede combinarse con JUnit para desa-rrollar tests que verifican el correcto funcionamiento de una aplicación Web.Desarrollado en Java, simula el comportamiento principal de un navegadorcomo el envío de formularios, soporte de Javascript o cookies.

Las mismas técnicas empleadas por HTTPUnit sirven para desarrollar testssobre servlets sin necesidad de un contenedor de servlets usando el módulo

http://selenium.openqa.org/

http://www.xprogramming.com/software.htm

http://www.xprogramming.com/software.htm

http://httpunit.sourceforge.net

6.6. iMacros 103

Figura 6.4: Ejemplo de rellenado de formularios con Selenium IDE.

ServletUnit.

Un ejemplo del uso de HTTPUnit puede verse en la Figura §6.5. Se navegahasta la dirección que contiene el formulario (líneas 2 y 3) y se instancia elpropio formulario (línea 4). Se rellena el campo del apellido del autor con elvalor deseado (líneas 6 y 7), se instancia el botón de búsqueda (líneas 9 y 10) yse simula un click sobre el botón de búsqueda (línea 11).

6.6. iMacros

iMacros (http://www.iopus.com/imacros/) es una herramienta para automa-tizar el acceso a la Web, el desarrollo de wrappers y el Web testing. Permite re-llenar formularios, simular clicks o navegar por páginas Web, también incluye

http://www.iopus.com/imacros/


1 WebConversation wc = new WebConversation();2 WebResponse resp = wc.getResponse(3 "http://www.booksexample.com"); // read this page4 WebForm form = resp.getForms()[0];5 // select the first form in the page6 form.setParameter("author_last",7 "Dick"); // fill last name89 Button searchBooksBtn = form.10 getButtonWithID("sbooks"); // get button11 searchBooksBtn.click(); // click button

Figura 6.5: Ejemplo de rellenado de formularios con HTTPUnit.

funciones de extracción de información. Los tests pueden generarse manual-mente escribiendo el código fuente en un lenguaje de script propio (Macros).iMacros puede usarse sólo o ser integrado con lenguajes de programación co-mo Java, C#, Python, etc., para todos estos lenguajes existen librerías que per-miten su integración.

Para ayudar a generar tests de manera automática, iMacros incluye unmódulo que permiten la grabación de tests. Estas grabaciones son realiza-das cuando el usuario interactúa con el navegador. Soporta el uso de InternetExplorer y Firefox, permite ejecutar tests que interactúen con Applets, Flash,Flex, Silverlight o AJAX.

Un ejemplo del uso de iMacros puede verse en la Figura §6.6. Se navegahasta la dirección que contiene el formulario (línea 1). Se rellena el campo delapellido del autor con el valor deseado (líneas 2 a 4) y se simula un click sobreel botón de búsqueda (líneas 5 y 6).

6.7. Otras herramientas

Otras herramientas que no estudiaremos en profundidad son: Java Inter-Face for Internet Explorer (Jiffie), Chickenfoot, IeUnit, Phyton-Javascript TestFramework (PyJTF), Avignon, Enterprise Web Test (EWT), JExplorer, JMeter,Watir Extension Toolkit (WET) o QA Wizard Pro.

6.8. Framework de comparación 105

1 URL GOTO=http://www.booksexample.com/2 TAG POS=1 TYPE=INPUT:TEXT3 FORM=ACTION:books_example.action4 ATTR=NAME:author_last CONTENT=Dick5 TAG POS=1 TYPE=INPUT:SUBMIT6 FORM=NAME: ATTR=ID:sbooks

Figura 6.6: Ejemplo de rellenado de formularios con iMacros.

Jiffie permite controlar Internet Explorer desde Java, permite la automati-zación de tests de regresión. Chickenfoot es una extensión para Firefox quepermite desarrollar scripts para la manipulación de páginas Web y la nave-gación automática. IeUnit es un framework simple que permite evaluar com-portamientos lógicos en páginas Web. PyJTF soporta el desarrollo basado entests de código Javascript empleando tests escritos en Python. Avignon es unsistema de tests de aceptación que permite la escritura de tests en un lenguajedeterminado.

EWT permite a los programadores Java escribir tests reusables para apli-caciones Web que son ejecutados sobre un navegador. JExplorer proporcionauna API en Java para integrar Internet Explorer en aplicaciones Java. JMeteres una aplicación de escritorio 100 % Java diseñada para generar tests funcio-nales y de stress. WET es una herramienta Web de automatización de tests queemplea Watir internamente. QA Wizard Pro automatiza los tests funcionalesy de regresión de aplicaciones Web.


Una vez visto un resumen de las herramientas existentes estudiamos unacomparativa entre ellas. Los resultados de esta comparativa pueden verse enla Tabla §6.1. En esta tabla se analiza si la herramienta soporta Internet Explo-rer (columna IE) o Firefox (Fx), si se permite la ejecución de la aplicación enbackground (Bg), si se permite la navegación por páginas Web (Nv), si permi-te el rellenado de formularios (Ff) y trabajar con Javascript y AJAX (JS y Axrespectivamente).


IE Fx Bg Nv Ff JS Ax

Watir Sí Sí Sí Sí Sí Sí No

Watij Sí No Sí Sí Sí Sí No

Watin Sí Sí Sí Sí Sí Sí Sí

HTTPUnit No No Sí Sí Sí Sí No

Selenium Sí Sí Sí Sí Sí Sí Sí

iMacros Sí Sí Sí Sí Sí Sí Sí

Jiffie Sí No No Sí Sí Sí No

Chickenfoot No Sí No Sí Sí Sí Sí

IEUnit Sí No Sí Sí Sí Sí No

PyJTF Sí No No No No No No

Avignon Sí Sí No Sí Sí No No

EWT Sí No No Sí Sí Sí No

JExplorer Sí No Sí Sí Sí Sí No

JMeter Sí Sí No Sí Sí No No

WET Sí No No Sí Sí No No

QA Wizard Sí Sí No Sí Sí Sí Sí

Tabla 6.1: Comparativa de herramientas comerciales estudiadas.

6.9. Conclusiones

Haciendo un análisis de la Tabla §6.1 se extraen algunas conclusiones. Exis-te una gama amplia y variada de herramientas que pueden emplearse para elrellenado y la navegación. Hemos visto que, aunque el objetivo de estas he-rramientas es el Web testing, no hay ningún inconveniente en aplicarlas a latareas del rellenado y navegación.

En cuanto al soporte que ofrecen, muchas de ellas soportan la mayoría denavegadores existentes (si no todos, los más utilizados), tecnologías recientescomo AJAX también son soportadas por algunas (aunque no la mayoría, comose puede comprobar en la Tabla §6.1). En cuanto al rellenado y la navegaciónen sí, son soportados por casi todas las herramientas.

Creemos que el soporte de nuevas tecnologías irá mejorando a lo largo


del tiempo en las distintas herramientas. Aquellas que tengan éxito tendránnuevas versiones que soporten más y mejor tecnología existente.

Como hemos visto, el rellenado y la navegación son ampliamente soporta-dos, por tanto, la decisión de qué herramienta elegir depende del resto de ca-racterísticas. Las herramientas como la serie Wati* (r, j y n), Selenium o iMacrosse perfilan como las mejores opciones. Estas herramientas tienen buen soportede navegadores y de tecnologías, son herramientas con suficientes versionescomo para estar bien depuradas.

Parte III

Consideraciones finales

Capítulo 7

Conclusiones

In this day and age, David, nothing costs more than information.

Gigolo Joe, Artificial Intelligence, 2001

E n este capítulo exponemos las conclusiones de este documento que secentran en dar respuesta a las cuestiones de investigación presenta-

das al inicio del mismo. Las diferentes respuestas proporcionadas también nosmarcan un camino de trabajo que es el que seguiremos durante el transcursode nuestra investigación.

112 Capítulo 7. Conclusiones

7.1. Introducción

Al principio de este documento presentamos una serie de cuestiones de in-vestigación derivadas de nuestra hipótesis inicial. A lo largo de este documen-to hemos hecho un estudio del estado del arte para cada cuestión de investiga-ción. Hemos investigado sobre el modelado de formularios de búsqueda, loslenguajes de consulta de alto nivel para la Web semántica y las herramientascomerciales para el rellenado de formularios y la navegación Web.

Por cada cuestión de investigación propuesta presentamos las conclusio-nes que hemos obtenido. Estas conclusiones nos marcan una línea de trabajoa seguir que constituye nuestro trabajo futuro.

7.2. Modelado de formularios de búsqueda (CI1.1)

Los actuales formularios de búsqueda están diseñados por/para usuarios,¿se puede obtener un modelo computacional de los formularios de búsqueda?

Es necesario modelar un formulario de búsqueda para poder procesarlomediante ordenador. Chang et al. [12, 20, 21, 56], Meng et al. [23, 24, 52, 55], Ál-varez et al. [1], Garcia-Molina et al. [28, 45, 46] y otros autores [17, 31, 32, 38, 39]tienen numerosos trabajos en este sentido. El modelo propuesto por Meng etal. es el más completo al contemplar muchas características de los formula-rios de búsqueda. Los trabajos existentes resuelven muchos de los problemasencontrados como la extracción automática de etiquetas, la identificación deatributos o las correspondencias semánticas.

Creemos que los esfuerzos de investigación en cuanto al modelado de for-mularios gira en torno al descubrimiento automático de: campos obligatorios,las relaciones lógicas existentes entre atributos, orden entre campos del formu-lario y tipo de un atributo (si se emplea para consultar datos o no). Por último,el modelo debe aceptar consultas expresadas en algún lenguaje de alto nivelque es un tema de investigación aún por explorar.

7.3. Lenguajes de alto nivel (CI2)

¿Existen lenguajes de alto nivel en la actualidad?

7.4. Herramientas para el rellenado y navegación (CI3) 113

SQL es el lenguaje de alto nivel más conocido, sin embargo, está muy orien-tado a bases de datos relacionales. Para la integración de aplicaciones Web, esnecesario un lenguaje de consulta no tan ligado a las bases de datos. Este len-guaje de consulta puede ser alguno de los empleados para consultar la Websemántica, en concreto, los lenguajes de consulta sobre RDF.

Existen multitud de lenguajes que sirven para consultar RDF, sin embargo,SPARQL es el único de todos ellos que está recomendado por el W3C, por tan-to, parece ser el candidato ideal para ser usado en integración de aplicacionesWeb.

7.4. Herramientas para el rellenado y navegación(CI3)

¿Existen tecnologías en la actualidad para realizar el rellenado de formula-rios y la navegación por las aplicaciones Web?

En la actualidad, las herramientas comerciales para el rellenado de formu-larios y la navegación son aquellas que se emplean en el Web testing. Las he-rramientas comerciales soportan casi todos los navegadores existentes y unagran gama de tecnologías Web como AJAX, Javascript, Flash o Silverlight.

La serie Wati* (Watij, Watir o Watin), Selenium o iMacros son algunas delas herramientas mejor posicionadas al tener incorporadas muchas (o todas)las características estudiadas en la comparativa. Estas características son lasque consideramos más deseables en nuestra investigación.

7.5. Otras cuestiones y trabajo futuro

Las cuestiones CI1.2, CI1.3 y CI4 han quedado sin responder en este do-cumento por cuestiones de planificación. Nuestro trabajo futuro pasa por in-vestigar estas cuestiones relativas a la viabilidad de consultas de alto nivel(CI1.2), los planes de ejecución de cuando se consultan varias fuentes de datosintegradas (CI1.3) y, la navegación por los resultados ofrecidos por una páginauna vez que el formulario es rellenado y enviado a la aplicación.

En el estudio del modelado de formularios (CI1.1) se han detectado algu-nos puntos a mejorar o que, a nuestro entender, no han sido abordados aún.Algunos de estos problemas son, por ejemplo, el orden de rellenado de los

114 Capítulo 7. Conclusiones

campos en un formulario o la aceptación de consultas en lenguaje de alto ni-vel por parte del modelo de formularios.

Parte IV

Apéndices

Apéndice A

Implementación de un enquirer

Do... or do not. There is no try.

Yoda, The Empire Strikes Back, 1980

E n este capítulo damos una visión general de la implementación deltrabajo de Álvarez et al. sobre un framework para representar la ca-

pacidad de consulta de fuentes de datos.

118 Apéndice A. Implementación de un enquirer

A.1. Introducción

Partiendo de [41], donde se describe el trabajo de Álvarez et al. en cuanto ala capacidad de consulta de fuentes de datos, realizamos una implementacióndel framework que permite calcular la capacidad de consulta del esquemaglobal que forman las fuentes a integrar. Esta implementación está descrita en[48–50].

Para la implementación hemos usado el entorno de desarrollo Eclipse y laversión 5 de Java (1.5). El trabajo original no menciona nada de cómo rellenarlos formularios de búsqueda de las aplicaciones integradas, nosotros hemoscontribuido implementando un módulo que rellena formularios a partir deconsultas SQL, este módulo se ha implementado con Watij (ver §6.3 para unabreve descripción de Watij y un ejemplo descriptivo).

A.2. Arquitectura

La arquitectura del sistema construido puede verse en la Figura §A.1. Elmódulo Query Capability Computer recibe las relaciones base y globales, pa-ra las globales, se calcula su capacidad de consulta. Query Executor aceptalas consultas especificadas por el usuario y las relaciones del módulo anterior,ambas entradas son suministradas a Matcher que se encarga de evaluar si unaconsulta es viable o no. Si es viable, External Query Executor hace efectiva laconsulta ejecutándola sobre las relaciones oportunas. La ejecución sobre for-mularios de búsqueda reales son simuladas por External DB y los datos ofre-cidos son almacenados en Local DB. Si las técnicas de postprocesado estánactivadas, los datos locales son filtrados para obtener la información final. Enla Figura §A.2 se presenta un diagrama de actividad del comportamiento delsistema.

A.3. Rellenado de formularios

La propuesta original apenas hace referencia al rellenado de formularios apartir de una consulta de usuario. En este caso nuestra contribución es que losatributos del modelo se corresponden con uno o más campos del formulariode búsqueda. De esta forma, para rellenar los campos del formulario, es ne-cesario efectuar una serie de transformaciones desde los valores especificadosen la consulta de usuario hasta los valores esperados por el formulario.

A.3. Rellenado de formularios 119

Query Capability ComputerRelations

(Base and/or Global)

Query Executor

Queries

Matcher

External Query Executor

External DB Local DB

Figura A.1: Arquitectura de la implementación.

User

Relations

Queries

Query Capability Computer

Computing global schema query

capabilities

Obtained Relations

Query Executor

Query execution over relations

Relation & Query

Matcher

Matching

Feasible?

External Query Executor

Execute query over HTML Forms and

store returning data

[Y]

Post-processing?

[Y]

Results

Execute query over stored data

Figura A.2: Diagrama de actividades de la implementación.

Este módulo únicamente necesita por parte del usuario un fichero XML conla configuración de las correspondencias entre atributos del modelo y camposdel formulario de búsqueda. Sumado a estas correspondencias es necesario

120 Apéndice A. Implementación de un enquirer

especificar la transformación a usar entre los valores de la consulta y los de loscampos del formulario.

A.4. Conclusiones

Una vez implementado el sistema, llegamos a la conclusión de que existenalgunos problemas que no son abordados en el trabajo original. Uno de losprincipales problemas es que las relaciones y los formularios de búsqueda noestán relacionados. La propuesta es tan amplia que puede ser usada con cual-quier fuente de información (no sólo formularios de búsqueda sino ficherosXML o de texto, por ejemplo), por tanto, existe una gran diferencia entre larelación y un formulario de búsqueda.

Otro problema es la semántica interna de los campos de un formulario: re-cibiendo una consulta con una serie de valores en los atributos, ¿cómo se haceefectiva en los campos de un formulario? Es necesario conocer las relacioneslógicas entre los campos de los formularios para saber cómo se consulta la ba-se de datos oculta. Los campos del formulario pueden depender unos de otrosy estas dependencias deben de ser analizadas. El formulario puede tener uncierto orden de rellenado de campos.

El trabajo estudiado es muy útil a la hora de representar una amplia varie-dad de fuentes de datos, incluidos los formularios de búsqueda, y proporcionauna representación simple ya que un usuario puede entender el modelo de lacapacidad de consulta de una fuente.

Apéndice B

Ejemplo motivador

If you ever travel back in time, don’t step on anything because even the tiniest change can alterthe future in ways you can’t imagine.

Homer remembers his father’s advice on his wedding day, The Simpsons, 1994

E n este capítulo establecemos nuestro ejemplo de estudio consistenteen un formulario de búsqueda de compra de libros. Estudiamos los

distintos bancos de pruebas existentes y presentamos algunos formularios deaplicaciones pertenecientes a la hidden Web. Por último, hacemos público elcódigo fuente de nuestro formulario de ejemplo.

122 Apéndice B. Ejemplo motivador

Figura B.1: Formulario de ejemplo.

B.1. Ejemplo de estudio

Se hace necesaria la existencia de un formulario de estudio para poder serusado como ejemplo en la descripción de las distintas propuestas encontradasen la bibliografía. Observamos que uno de los dominios temáticos más estu-diados es la venta de libros. Nuestro formulario de ejemplo puede verse en laFigura §B.1.

Un campo es una entrada del formulario que el usuario puede rellenar,coincide con los controles típicos de HTML como las cajas de texto, las listasde selección o los checkboxes. Una etiqueta es un texto explicativo que apareceen el formulario para que un usuario detecte visualmente a qué concepto hacereferencia uno o varios campos. Normalmente la etiqueta se encuentra próxi-ma al campo(s) al que hace referencia. Un atributo de dominio es un conjuntode elementos (campos y etiquetas) que están relacionados (normalmente pró-ximos) y que representan un concepto del dominio. Los atributos del dominioconsultan los datos de la aplicación Web. Un atributo de presentación es seme-jante a un atributo de dominio aunque, en lugar de referirse a un concepto deldominio, afectan a cómo son presentados los resultados al enviar el formularioa la aplicación.

B.1. Ejemplo de estudio 123

Un campo puede ser de dominio o restricción. Los campos de dominio sonaquellos campos que forman parte de un atributo y permiten al usuario relle-narlos con valores que afectan al dominio. Los campos de restricción son aque-llos campos que forman parte de un atributo y permiten al usuario rellenarloscon valores que afectan a cómo es consultado el dominio, normalmente impo-niendo restricciones sobre los datos. Siempre que nos referimos a un atributoo un campo lo hacemos a través de su etiqueta por simplicidad, asumiendoque un campo o un atributo es una estructura mucho más compleja que unasimple etiqueta.

En la Figura §B.2 se observa todas las partes de las que está compuestoel formulario de ejemplo. Un ejemplo de atributo de dominio es Author, laetiqueta que designa a este atributo es “Author” y está compuesto por doscampos con sus respectivas etiquetas Last Name, cuya etiqueta es “Last Name*” y First Name cuya etiqueta es “First Name”. Las cajas de texto próximasa cada etiqueta son las que permiten especificar valores del dominio y, portanto, son campos de dominio. La relación existente entre ambos campos esde tipo parte, por eso forman un atributo de dominio de tipo Parte.

Title es un atributo que, además de contener un campo de dominio, tieneuna agrupación de campos de tipo restricción, estos campos afectan a cómo estratado el texto que se rellena en la caja de texto del título. Publication Yeary Price Range son atributos de tipo Rango porque permiten especificar unrango de valores para un concepto. Check bargains? es un atributo de tipobooleano y Display es un atributo de presentación, al afectar al número deregistros que se muestran en la respuesta.

La semántica del formulario es la siguiente: para consultar por el campoAuthor, debemos de introducir su nombre y apellido (en los campos FirstName y Last Name respectivamente). El apellido del autor es obligatorio (mar-cado con asterisco). Si se desea consultar por título del libro, se puede elegircómo se va a interpretar el texto que aparece dentro de la caja de texto, estose hace mediante los botones radio que aparecen debajo: ‘Title word(s)’ buscalas palabras sueltas en el título, ‘Start(s) of title word(s)’ busca las palabras alcomienzo del título, y ‘Exact start of title’ filtra el título exacto.

Además de estas características, existe una serie de campos para refinaraún más la búsqueda. Para el año de publicación puede elegirse un rango deaños a buscar. La lista de selección que indica el principio de rango (“after”)nunca puede tener un valor superior a la del fin del rango (“before”). Tambiénpuede especificarse un rango de precios expresado en dólares de EEUU (US$),así como el formato del libro a buscar. Display contiene una lista de selecciónpara paginar los resultados que nos devuelva la consulta de un formulario.


Attribute label

Domain attribute

Part

Field label Domain

fieldConstraint field

Range

Group

Boolean attribute

Display attribute

Figura B.2: Explicación del formulario de ejemplo.

Este formulario de ejemplo es un compendio de los diferentes formulariosde estudio de los trabajos analizados.

B.2. Bancos de pruebas

Uno de los principales aspectos en la investigación científica es la experi-mentación. En nuestra investigación, los trabajos estudiados emplean distin-tos bancos de pruebas para experimentar con las propuestas. Algunos de estosbancos de pruebas son generados aleatoriamente y no se desvela públicamen-te el contenido de los mismos.

Un banco de pruebas disponible públicamente es UIUC Repository (http://metaquerier.cs.uiuc.edu/repository/). En este repositorio existe una serie deformularios recopilados de diferentes aplicaciones Web pertenecientes a lahidden Web. Se permiten añadir nuevas contribuciones al banco de pruebas.El repositorio contiene varios conjuntos de datos:

TEL-8 Query Interfaces: Creado en mayo de 2003, recoge 447 formula-

http://metaquerier.cs.uiuc.edu/repository/

http://metaquerier.cs.uiuc.edu/repository/

B.2. Bancos de pruebas 125

Domain Web apps number Forms number

Airfares 47 49

Automobiles 84 97

Books 65 67

Car Rentals 25 25

Hotels 39 39

Jobs 49 52

Movies 73 78

Music Records 65 70

Tabla B.1: Número de aplicaciones Web y de formularios de TEL-8.

rios de 8 dominios distintos agrupados en 3: TEL, Travel (vuelos, hote-les y alquiler de coches), Entertainment (libros, películas y discos) y Li-ving (trabajo y automóviles). Los creadores de este repositorio son KevinChen-Chuan Chang, Bin He, Chengkai Li y Zhen Zhang todos vincula-dos a UIUC.

Para cada aplicación Web, este conjunto de datos tiene archivado copiasde la página principal y de las páginas que contienen formularios, ade-más de enlaces a las URLs originales. Contiene la capacidad de consultade las aplicaciones extraídas manualmente. Estas páginas han podidoquedar desfasadas al ser almacenadas y cambiar la página original.

Este conjunto de datos fue recolectado originalmente en diciembre de2002 y revisado en numerosas ocasiones hasta mayo de 2003. Las pági-nas que lo componen han sido encontradas manualmente en diferentesdirectorios Web (como http://www.invisibleweb.com [después http://www.profusion.com y actualmente desaparecida], http://www.completeplanet.com, http://dir.yahoo.com, etc.) y los motores de búsqueda generales (co-mo Google).

Una aplicación Web es considerada como de la hidden Web si la infor-mación estructurada que almacena se puede consultar haciendo uso deformularios de búsqueda. Este repositorio está disponible para descar-gar. El número de aplicaciones Web y de formularios de búsqueda anali-zados pueden verse en la Tabla §B.1. Este repositorio ha sido usado pararealizar pruebas sobre la extracción de la capacidad de consulta y lascorrespondencias semánticas.

http://www.invisibleweb.com

http://www.profusion.com

http://www.profusion.com

http://www.completeplanet.com

http://www.completeplanet.com

http://dir.yahoo.com


Domain Web apps number

Books 55

Automobiles 55

Movies 52

Music Records 49

Tabla B.2: Número de formularios de BAMM.

BAMM Extracted Query Schemas: Creado en noviembre de 2002, recogelos atributos de los formularios de búsqueda de unas 200 aplicacionesWeb de 4 dominios: Books, Automobiles, Movies y Music Records. Loscreadores son Bin He y Kevin Chen-Chuan Chang de UIUC. Por cadaaplicación Web encontrada, se han extraído manualmente los nombresde los atributos que posee cada formulario de búsqueda encontrado.

Existe una versión para poder ser descargada de este repositorio. En laTabla §B.2 puede verse el número de formularios encontrado para cadadominio. Este repositorio ha sido usado para realizar pruebas sobre lascorrespondencias semánticas.

ICQ Query Interfaces: Recoge 100 formularios de búsqueda de aplica-ciones Web de 5 dominios: vuelos, libros, automóviles, trabajo y pro-piedades inmobiliarias. Los creadores son Wensheng Wu y AnHai Doan(UIUC), Clement Yu (Universidad de Illinois en Chicago) y Weiyi Meng(SUNY en Binghamton). Este repositorio ha sido usado para probar laspropuestas sobre correspondencias semánticas.

Para la recolección de los formularios se han utilizado dos directorios,un directorio es http://www.invisibleweb.com que mantiene un listado deaplicaciones de la hidden Web y enlaces directos a los formularios debúsqueda. El otro directorio es http://dir.yahoo.com que no almacena lainformación de los formularios ni si es una aplicación de la hidden Web,por tanto, hubo que realizar estas identificaciones automáticamente. Losformularios se transforman en árboles y son almacenados.

IWRandom: Creado en Noviembre de 2003, contiene 33 formularios debúsqueda extraídos de los 16 dominios más importantes de http://www.invisible-web.net/. Los creadores son Zhen Zhang, Bin He y Kevin Chen-Chuan Chang de UIUC. Este repositorio ha sido empleado para probarla extracción automática de la capacidad de consulta. Existe una versiónpara descargar este repositorio completo.

http://www.invisibleweb.com

http://dir.yahoo.com

http://www.invisible-web.net/

http://www.invisible-web.net/

B.3. Formularios de búsqueda de la hidden Web 127

Figura B.3: Formularios de búsqueda de libros.

OntoBuilder: Contiene más de 100 ontologías de 14 dominios diferen-tes. Creado por Avigdor Gal et al. de Technion en Israel Institute of Te-chnology. Las ontologías se proporcionan codificadas en XML. Todas lasontologías están disponibles para ser descargadas.

B.3. Formularios de búsqueda de la hidden Web

Para dar una idea de la gran variedad de formularios de búsqueda exis-tente en las aplicaciones de la hidden Web proporcionamos algunos ejemplosde formularios. Hemos divido los formularios en tres dominios temáticos, losformularios de búsqueda de venta de libros pueden verse en la Figura §B.3,los de venta de música en la Figura §B.4, y los de venta de DVDs en la Figura§B.5.

Estos formularios han sido extraídos de Amazon (http://www.amazon.com), Barnes & Noble (http://www.barnesandnoble.com) y Fnac (http://www.fnac.es) en julio de 2008.

http://www.amazon.com

http://www.amazon.com

http://www.barnesandnoble.com

http://www.fnac.es

http://www.fnac.es


Figura B.4: Formularios de búsqueda de música.

B.4. Código fuente del formulario de ejemplo

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"><html><head><title>Books Example</title></head><body>

<form action="books_example.action"><table cellpadding="2" cellspacing="0">

<tbody><tr><td colspan="2" bgcolor="#e1e1cc"><font face="Verdana" size="-1">Author</font></td></tr><tr><td>

B.4. Código fuente del formulario de ejemplo 129

Figura B.5: Formularios de búsqueda de DVDs.

<font face="Verdana" size="-1">Last Name*</font>

</td><td>

<font face="Verdana" size="-1">FirstName</font>

</td></tr><tr><td>

<input maxlength="30" size="31"name="author_last">

</td>


<td><input maxlength="30" size="31"

name="author_first"></td>

</tr><tr><td colspan="2" bgcolor="#e1e1cc"><font face="Verdana" size="-1">Title</font></td></tr><tr><td colspan="2">

<input maxlength="30" size="67"name="title">

</td></tr><tr><td colspan="2">

<font size="-1"><input checked="checked" value="title" name="field-1"

type="radio"> Title word(s)<input value="title-words-begin" name="field-1" type="radio">

Start(s) of title word(s)<input value="title-begins" name="field-1" type="radio">

<i>Exact</i> start of title</font>

</td></tr></tbody></table><p><hr color="#e1e1cc" size="2" width="430" align="left" /></p><font face="Verdana" size="-1"> Refine your search: </font><br><br><table cellpadding="2" cellspacing="0"><tbody><tr><td>


<font face="Verdana" size="-1">PublicationYear:</font>

</td><td align="right"><font size="-1">after</font></td><td><select name="year-after">

<option>2000</option><option>2001</option><option>2002</option><option>2003</option><option>2004</option><option>2005</option><option>2006</option><option>2007</option><option>2008</option><option>2009</option>

</select></td><td align="right">

<font size="-1">before</font>

</td><td>

<select name="year-before"><option>2000</option><option>2001</option><option>2002</option><option>2003</option><option>2004</option><option>2005</option><option>2006</option><option>2007</option><option>2008</option><option>2009</option>


</select></td></tr><tr><td>

<font face="Verdana" size="-1">PriceRange:</font>

</td><td align="right">

<font size="-1">between US$</font>

</td><td><input maxlength="5" size="5" name="price_between_low"></td><td align="right"><font size="-1">and US$</font></td><td><input maxlength="5" size="5" name="price_between_high"></td></tr><tr><td width="1">

<font face="Verdana"size="-1">Format:</font>

</td><td colspan="4"><font size="-1"><input value="hard" name="format" type="checkbox"> Hardcover<input value="paper" name="format" type="checkbox"> Paperback<input value="ebooks" name="format" type="checkbox"> e-Books &Docs</font></td></tr>


<tr><td width="1"><font face="Verdana" size="-1">Checkbargains?:</font></td><td colspan="4"><font size="-1"><input value="yesno" name="bargains" type="checkbox"></font></td></tr><tr><td><font face="Verdana" size="-1">Display:</font></td><td colspan="4"><select name="display"><option>10</option>

<option>20</option></select></td></tr></tbody></table><p><hr color="#e1e1cc" size="2" width="430" align="left" /></p><br><input name="sbooks" id="sbooks" value="Search Books!"type="submit"></form></body></html>

Bibliografía

[1] M. Álvarez, J. Raposo, A. Pan, F. Cacheda, F. Bellas y V. Carneiro. Cra-wling the Content Hidden Behind Web Forms. En ICCSA (2), páginas322–333, 2007

[2] G. Antoniou y F. vanHarmelen. A Semantic Web Primer. MIT Press,Cambridge, MA, USA, 2004

[3] L. Barbosa y J. Freire. Searching for Hidden-Web Databases. En WebDB,páginas 1–6, 2005

[4] D. Beckett. RDF/XML Syntax Specification (Revised). Informe técnico,W3C, 2004. Disponible en http://www.w3.org/TR/rdf-syntax-grammar/

[5] M. K. Bergman. WHITE PAPER: The Deep Web: Surfacing Hidden Value.Ann Arbor, Michigan: Scholarly Publishing Office, University of Michi-gan University Library. Journal of Electronic Publishing, 7(1), 2001. Dis-ponible en http://hdl.handle.net/2027/spo.3336451.0007.104

[6] T. Berners-Lee, J. Hendler y O. Lassila. The Semantic Web. ScientificAmerican, 2001

[7] J. Broekstra. Sesame RQL: a Tutorial. Informe técnico, Aduna Software,2004. Disponible en http://www.openrdf.org/doc/rql-tutorial.html

[8] J. Broekstra. The SeRQL query language. Informe técnico, Aduna Softwa-re, 2004. Disponible en http://www.openrdf.org/doc/sesame/users/ch06.html

[9] C.-H. Chang, M. Kayed, M. R. Girgis y K. F. Shaalan. A Survey of WebInformation Extraction Systems. IEEE Trans. Knowl. Data Eng., 18(10):1411–1428, 2006

[10] K. C.-C. Chang y H. Garcia-Molina. Mind Your Vocabulary: Query Map-ping Across Heterogeneous Information Sources. En SIGMOD Conferen-ce, páginas 335–346, 1999

http://www.w3.org/TR/rdf-syntax-grammar/

http://hdl.handle.net/2027/spo.3336451.0007.104

http://www.openrdf.org/doc/rql-tutorial.html

http://www.openrdf.org/doc/sesame/users/ch06.html

http://www.openrdf.org/doc/sesame/users/ch06.html

136 Bibliografía

[11] K. C.-C. Chang, B. He, C. Li, M. Patel y Z. Zhang. Structured Databases onthe Web: Observations and Implications. SIGMOD Record, 33(3):61–70,2004

[12] K. C.-C. Chang, B. He y Z. Zhang. Toward Large Scale Integration: Buil-ding a MetaQuerier over Databases on the Web. En CIDR, páginas 44–55,2005

[13] R. P. Díaz. Implementing Faceted Classification for Software Reuse. Com-mun. ACM, 34(5):88–97, 1991

[14] A. Doan y A. Y. Halevy. Semantic Integration Research in the DatabaseCommunity: A Brief Survey. AI Magazine, 26(1):83–94, 2005

[15] E. C. Dragut, C. T. Yu y W. Meng. Meaningful Labeling of IntegratedQuery Interfaces. En VLDB, páginas 679–690, 2006

[16] J. Euzenat y P. Shvaiko. Ontology matching. Springer-Verlag, Heidelberg(DE), 2007

[17] A. Gal, G. A. Modica, H. M. Jamil y A. Eyal. Automatic Ontology Mat-ching Using Application Semantics. AI Magazine, 26(1):21–32, 2005

[18] P. Haase, J. Broekstra, A. Eberhart y R. Volz. A comparison of rdf querylanguages. En International Semantic Web Conference, páginas 502–517,2004

[19] A. Y. Halevy, N. Ashish, D. Bitton, M. J. Carey, D. Draper, J. Pollock, A. Ro-senthal y V. Sikka. Enterprise information integration: successes, challen-ges and controversies. En SIGMOD Conference, páginas 778–787, 2005

[20] B. He y K. C.-C. Chang. Statistical Schema Matching across Web QueryInterfaces. En SIGMOD Conference, páginas 217–228, 2003

[21] B. He, K. C.-C. Chang y J. Han. Discovering complex matchings acrossWeb query interfaces: a correlation mining approach. En KDD, páginas148–157, 2004

[22] B. He, T. Tao y K. C.-C. Chang. Organizing structured Web sources byquery schemas: a clustering approach. En CIKM, páginas 22–31, 2004

[23] H. He, W. Meng, Y. Lu, C. T. Yu y Z. Wu. Towards Deeper Understandingof the Search Interfaces of the Deep Web. En World Wide Web, páginas133–155, 2007

Bibliografía 137

[24] H. He, W. Meng, C. T. Yu y Z. Wu. WISE-Integrator: An Automatic In-tegrator of Web Search Interfaces for E-Commerce. En VLDB, páginas357–368, 2003

[25] A. Heß y N. Kushmerick. Learning to Attach Semantic Metadata to WebServices. En International Semantic Web Conference, páginas 258–273,2003

[26] G. Kabra, C. Li y K. C.-C. Chang. Query Routing: Finding Ways in theMaze of the DeepWeb. En WIRI, páginas 64–73, 2005

[27] Y. Kalfoglou y W. M. Schorlemmer. Ontology Mapping: The State of theArt. En Semantic Interoperability and Integration, 2005

[28] O. Kaljuvee, O. Buyukkokten, H. Garcia-Molina y A. Paepcke. EfficientWeb form entry on PDAs. En WWW, páginas 663–672, 2001

[29] B. Kitchenham. Procedures for performing systematic reviews. Informetécnico, Keele University and NICTA, 2004

[30] N. Kushmerick. Wrapper verification. World Wide Web, 3(2):79–94, 2000

[31] N. Kushmerick. Learning to Invoke Web Forms. En Co-opIS/DOA/ODBASE, páginas 997–1013, 2003

[32] J. P. Lage, A. S. da Silva, P. B. Golgher y A. H. F. Laender. Automaticgeneration of agents for collecting hidden Web pages for data extraction.Data Knowl. Eng., 49(2):177–196, 2004

[33] K. Lerman, S. Minton y C. A. Knoblock. Wrapper Maintenance: A Ma-chine Learning Approach. J. Artif. Intell. Res. (JAIR), 18:149–181, 2003

[34] S. W. Liddle, D. W. Embley, D. T. Scott y S. H. Yau. Extracting Data behindWeb Forms. En ER (Workshops), páginas 402–413, 2002

[35] Y. Lu, H. He, Q. Peng, W. Meng y C. T. Yu. Clustering e-commerce searchengines based on their search interface pages using WISE-Cluster. DataKnowl. Eng., 59(2):231–246, 2006

[36] J. Madhavan y A. Halevy. Crawling through HTML forms.Official Google Webmaster Central Blog, 2008. Disponi-ble en http://googlewebmastercentral.blogspot.com/2008/04/crawling-through-html-forms.html

http://googlewebmastercentral.blogspot.com/2008/04/crawling-through-html-forms.html

http://googlewebmastercentral.blogspot.com/2008/04/crawling-through-html-forms.html

138 Bibliografía

[37] R. McCann, B. K. AlShebli, Q. Le, H. Nguyen, L. Vu y A. Doan. MappingMaintenance for Data Integration Systems. En VLDB, páginas 1018–1030,2005

[38] G. A. Modica, A. Gal y H. M. Jamil. The Use of Machine-Generated On-tologies in Dynamic Information Seeking. En CoopIS, páginas 433–448,2001

[39] H. Nguyen, T. Nguyen y J. Freire. Learning to Extract Form Labels. EnVLDB, 2008

[40] N. F. Noy. Semantic Integration: A Survey Of Ontology-Based Approa-ches. SIGMOD Record, 33(4):65–70, 2004

[41] A. Pan, P. Montoto, A. Molano, M. Álvarez, J. Raposo yÁ. Viña. A Modelfor Advanced Query Capability Description in Mediator Systems. EnICEIS, páginas 140–147, 2002

[42] Q. Peng, W. Meng, H. He y C. T. Yu. WISE-cluster: clustering e-commercesearch engines automatically. En WIDM, páginas 104–111, 2004

[43] E. Prud’hommeaux y B. Grosof. RDF Query Survey. Infor-me técnico, W3C, 2004. Disponible en http://www.w3.org/2001/11/13-RDF-Query-Rules/

[44] E. Prud’hommeaux y A. Seaborne. SPARQL Query Language forRDF. Informe técnico, W3C, 2006. Disponible en http://www.w3.org/TR/rdf-sparql-query/

[45] S. Raghavan y H. Garcia-Molina. Crawling the Hidden Web. Informetécnico, Computer Science Dept., Stanford University, 2000

[46] S. Raghavan y H. Garcia-Molina. Crawling the Hidden Web. En VLDB,páginas 129–138, 2001

[47] E. Rahm y P. A. Bernstein. A survey of approaches to automatic schemamatching. VLDB J., 10(4):334–350, 2001

[48] C. Rivero. From Queries to Search Forms: An Implementation. Interna-tional Journal of Computer Applications in Technology, 2008

[49] C. Rivero y D. Ruiz. An Advanced Query Capability Description Frame-work Implementation. En Zoco Workshop/JISBD, 2007

[50] C. Rivero y D. Ruiz. Implementing a Web Form Filler. En Zoco Works-hop/CAEPIA, 2007

http://www.w3.org/2001/11/13-RDF-Query-Rules/

http://www.w3.org/2001/11/13-RDF-Query-Rules/

http://www.w3.org/TR/rdf-sparql-query/

http://www.w3.org/TR/rdf-sparql-query/

Bibliografía 139

[51] A. Seaborne. RDQL - A Query Language for RDF. Informe téc-nico, W3C, 2004. Disponible en http://www.w3.org/Submission/2004/SUBM-RDQL-20040109/

[52] L. Shu, W. Meng, H. He y C. T. Yu. Querying Capability Modeling andConstruction of Deep Web Sources. En WISE, páginas 13–25, 2007

[53] P. Shvaiko y J. Euzenat. A Survey of Schema-Based Matching Approa-ches. páginas 146–171, 2005

[54] J. Turmo, A. Ageno y N. Català. Adaptive information extraction. ACMComput. Surv., 38(2), 2006

[55] W. Wu, C. T. Yu, A. Doan y W. Meng. An Interactive Clustering-basedApproach to Integrating Source Query interfaces on the Deep Web. EnSIGMOD Conference, páginas 95–106, 2004

[56] Z. Zhang, B. He y K. C.-C. Chang. Understanding Web Query Interfa-ces: Best-Effort Parsing with Hidden Syntax. En SIGMOD Conference,páginas 107–118, 2004

[57] Z. Zhang, B. He y K. C.-C. Chang. Light-weight Domain-based FormAssistant: Querying Web Databases On the Fly. En VLDB, páginas 97–108, 2005

http://www.w3.org/Submission/2004/SUBM-RDQL-20040109/

http://www.w3.org/Submission/2004/SUBM-RDQL-20040109/

140 Bibliografía

This document was typeset on // using RC–BOOK α. for LATEX2ε.Should you want to use this document class, please send mail to

[email protected].

mailto:[email protected]

integraciÓn de aplicaciones w - lsi.us.es · integraciÓn de aplicaciones web ### automatizaciÓn...

Documents