574 IEEE LATIN AMERICA TRANSACTIONS, VOL. … · desarrollado en la Universidad de Illinois [21]...

1Abstract— With the constant increase in the volume of information available on the Web, it is more dificult to find the specific information related to a given domain. Users are facing the problem of information overload, in which a query about a specialized subject (local information, e-commerce: hotels, airlines, car rental; science: biology, mathematics, medicine, etc.) on a web search engine, it returns a lot of web pages or results that in most of the cases are outside the domain of interest. This is one reason why the vertical search tools have become a necessity for users that seek specific-domain information from diferent databases available in the Web through input sources called Web Query Interfaces (ICWs). This paper describes an approach for automatic integration of ICWs, a crucial task to construct vertical search tools. The proposed methodology is validated by realizing a vertical search prototype called VSearch that allows users to transparently query multiple web databases in a specific-domain through a unified ICW. The proposed approach for automatic ICWs integration is based on: i) a hierarchical model called AEV for modeling the visual content of ICW; ii) semantic clustering for the identification of relationships between fields in ICWs; and iii) a field homogenization and unification process of AEV schemes for the construction of a unified ICW. The VSearch prototype was implemented and evaluated using a study case. The experimental results demonstrate the high precision in the integration phase and an efective methodology to create a functional vertical search tool for a given domain. Keywords— Vertical Search Tool, Web Databases, Web Query Interfaces, Automatic Integration, VSearch.

I. INTRODUCCIÓN

A Web Profunda se refiere a la información que radica en las bases de datos disponibles en la Web [10]. La

información disponible en estas bases de datos web se obtiene por los usuarios a través de consultas mediante formularios HTML especiales llamados Interfaces de Consulta Web (ICWs). Una ICW es un formulario HTML que permite a los usuarios enviar consultas estructuradas a una base de datos web y recibir una página web generada dinámicamente como respuesta a la consulta emitida [19]. Una ICW se compone de múltiples campos, etiquetas textuales asociadas a cada campo, imágenes digitales y componentes multimedia. Los campos más comunes son: cajas de texto (text-inputbox), listas de selección (selection-list), botones (radio-button) y caja de selección (check-box) [19]. La Fig. 1 muestra cuatro ICWs

H. M. Marin, Universidad Politécnica de Victoria, Cd. Victoria,

Tamaulipas, Mexico, [email protected] V. J. Sosa, CINVESTAV-LTI, Cd. Victoria, Tamaulipas, México,

[email protected] M. A. Nuño, Universidad Politécnica de Victoria, Cd. Victoria,

Tamaulipas, Mexico, [email protected]

relacionadas con el dominio de libros. Como se puede observar en la Fig. 1, a pesar de pertenecer al mismo dominio, las ICWs tienen un esquema heterogéneo de diseño, estilo, valor y capacidades de consulta, lo cual hace difícil de procesar de forma automática su información semántica para realizar el proceso de integración.

En la actualidad, existen múltiples bases de datos web especializadas disponibles (relacionadas con la venta de casas, información médic a, comercio electrónico, ciencias, etc.). Sin embargo, el proceso de consultar varias bases de datos web una por una se vuelve inviable para un usuario. En una situación como ésta, es necesario el uso de una herramienta de búsqueda vertical que permita integrar diferentes ICWs de un dominio específico con el fin de facilitar el proceso de búsqueda de los usuarios. El proceso de integración automática de ICWs consiste en formar una ICW unificada que sirva para recibir consultas web proporcionadas por el usuario distribuyendo dicha consulta a cada ICW de forma transparente al usuario, integrando cada resultado individual y presentando al usuario los resultados obtenidos en una forma útil y comprensible.

Figura 1. Ejemplo de cuatro diferentes ICWs en el dominio de “Libros” Para un dominio de interés, existen diversas ICWs en la

Web con capacidades de cobertura y de consulta variables. Sin embargo, no existe un mecanismo automático que integre ICWs de un mismo dominio y produzca una ICW unificada que facilite la consulta e incremente la cobertura de búsqueda.

Un usuario con una necesidad específica, por ejemplo, comprar un libro puede acceder a un sitio web popular como amazon.com para consultar información del libro y posiblemente realizar la compra. Sin embargo, sería más útil para el usuario consultar de forma transparente varias bases de

L

Automatic construction of vertical search tools for the Deep Web

H. M. Marin, V. J. Sosa and M. A. Nuño

574 IEEE LATIN AMERICA TRANSACTIONS, VOL. 16, NO. 2, FEB. 2018

datos web web y usar la información recabada de distintas fuentes, por ejemplo, el precio y el tiempo de entrega, para tomar una mejor decisión de compra. Considerando que existen diversas ICWs disponibles en la Web para un dominio dado (por ejemplo para el dominio de renta de hoteles o compra de boletos en aerolíneas), sería tedioso y requeriría de más tiempo para el usuario encontrar todas esas ICWs, llenar y enviar la consulta en cada una, e integrar los resultados para obtener la información de su interés de forma manual.

Bajo este contexto, en este trabajo, se proponen como contribuciones principales:

1. Un nuevo enfoque para la integración de ICWs basado en un modelo de representación jerárquica que usa la información visual de las ICWs dada por el motor de renderizado HTML (render engine). Esta información se presenta en un árbol de renderizado (render tree), al cual se le aplican diversos algoritmos de procesamiento para descartar información irrelevante (formato o estilo), identificar campos y sus etiquetas, agrupar y delimitar grupos de campos. El enfoque de integración propuesto usa el modelo jerárquico de cada ICW para producir de forma automática una ICW unificada, usando clustering de campos, homogenización y unificación de esquemas jerárquicos de ICWs.

2. Una metodología para la construcción automática de herramientas de búsqueda vertical que además del proceso de integración de ICWs, incluye los procesos de identificación y clasificación de ICWs como componentes previos para construir una ICW unificada.

3. Los resultados experimentales del prototipo de una herramienta de búsqueda vertical, llamado VSearch que implementa y valida la metodología propuesta para la construcción de este tipo de herramientas.

El resto de este artículo se encuentra estructurado de la

siguiente manera: En la Sección II se presenta el trabajo relacionado. Las secciones III, IV y V proveen detalles de cada una de las fases y procesos involucrados en la metodología propuesta para la construcción automática de herramientas de búsqueda vertical. La sección VI presenta los resultados obtenidos a partir del prototipo implementado, VSearch. Finalmente, en la sección VII se dan las conclusiones de este trabajo y direcciones para el trabajo futuro.

II TRABAJO RELACIONADO La construcción de una ICW unificada para un dominio

específico, a través de la identificación, clasificación e integración de ICWs individuales, ha sido abordada principalmente en [1, 14, 21].

DeepPeep [1] es un motor de búsqueda especializado en ICWs, desarrollado por la Universidad de Utah para ayudar a descubrir puntos de entrada a la Web Profunda, incluyendo bases de datos y servicios web. Sin embargo, DeepPeep no

considera el proceso de integración de ICWs, únicamente cubre los procesos de identificación y clasificación de ICWs de acuerdo a los dominios registrados por el motor de búsqueda. Además, no todas las páginas web recuperadas contienen ICWs, o las ICWs recuperadas no pertenecer al dominio seleccionado.

El proyecto llamado MetaQuerier es un trabajo desarrollado en la Universidad de Illinois [21] que se centra en el descubrimiento y consulta de bases de datos web. MetaQuerier se divide en dos sub-proyectos: MetaExplorer y MetaIntegrator.

Por un lado, MetaExplorer se centra en el descubrimiento, modelado, y la estructuración de las bases de datos web para construir un repositorio de búsqueda. Por otro lado, MetaIntegrator se utiliza para integrar ICWs correspondientes a un dominio determinado. El contenido interno de las ICWs se modela mediante una gramática 2P (patrón-precedencia), el cual es inherentemente ambiguo y puede generar falsos mapeos entre los campos de las ICWs, lo que hace a MetaIntegrator un proyecto incompleto.

El trabajo desarrollado por Kabish [14] considera los procesos de clasificación e integración de ICWs para la construcción de una única ICW. Sin embargo, dicho trabajo no resuelve los problemas de mapeo entre los campos, que pueden causar los falsos mapeos.

A diferencia de los enfoques previos, en este trabajo se presenta un nuevo enfoque para construir una herramienta de búsqueda vertical funcional para un dominio dado, considerando los procesos de identificación, clasificación e integración de ICWs, siendo esta última desarrollada bajo un enfoque diferente al propuesto por Kabish en [14] y en MetaIntegrator en [21]. La Tabla 1 resume los principales aspectos que diferencian el trabajo presentado en este documento respecto a otras propuestas.

Diferente al trabajo propuesto en [21], donde el proceso de integración se realiza utilizando una gramática 2P, nuestro trabajo es guiado por un enfoque jerárquico. Este modelo jerárquico se utiliza con el objetivo de mejorar el mapeo y unificación de campos entre las diferentes ICWs.

TABLA I

ENFOQUES PARA CONSTRUIR HERRAMIENTAS DE BÚSQUEDA VERTICAL PARA LA WEB PROFUNDA

Referencia Proyecto Identificación Clasificación Integración ICW unificada

[1] DeepPeep ü ü X X [21] MetaQuerier ü ü ü X [14] -- X ü ü X

Enfoque propuesto

VSearch ü ü ü ü Aunque en [14] también han propuesto un modelo

jerárquico para el proceso de integración de ICWs, en el presente trabajo se usa un enfoque diferente para este proceso. Los autores en [14] hipotetizan la existencia de un conjunto de reglas de diseño independientes del dominio que guían la creación de ICWs. Ellos describen un algoritmo de extracción

MARIN CASTRO et al.: AUTOMATIC CONSTRUCTION 575

de ICWs, que combina tokens HTML y la capa geométrica de estos tokens dentro de una página web. Entonces convierten el problema de extracción en un problema de integración. Los autores presentan ocho reglas que guían el diseño de ICWs. Cuatro de estas reglas destacan la importancia del estilo del texto para identificar etiquetas asociadas con campos, grupos, y super-grupos. Sin embargo, estas reglas no siempre pueden ser aplicadas dada la heterogeneidad existente en los diseños de ICWs. Por ejemplo, existen ICWs que manejan el mismo estilo de texto en todo el contenido, teniendo como única diferencia la identación y la localización de las etiquetas en el formulario HTML.

Además, el proceso de integración propuesto en el presente trabajo aborda el problema de relaciones semánticas entre campos. Este aspecto no se aborda en [14]. Sin embargo, es necesario abordar este problema para mejorar el proceso de integración de ICWs logrando una mejor correspondencia semánticamente entre campos de diferentes ICWs de dominio específico.

Trabajos reportados en la literatura sobre integración de ICWs como [5], [6], [7], [9], [11], [12], [13], [15], [17] sólo se han centrado en las tareas de extracción, modelado de ICWs y cálculo de relaciones semánticas entre campos de diferentes ICWs en el mismo dominio, esto debido a la complejidad de todo del proceso completo. Un número reducido de estos trabajos han sugerido que, con el fin de construir ICWs unificadas amigables al usuario, éstas deben exhibir importantes relaciones estructurales entre sus atributos. Uno de los objetivos del trabajo que se presenta en este artículo es proporcionar estas relaciones y reflejarlas en la ICW unificada.

III. METODOLOGÍA PARA LA CONSTRUCCIÓN DE

HERRAMIENTA DE BÚSQUEDA VERTICAL La metodología propuesta en este trabajo para la

construcción automática de herramientas de búsqueda vertical se muestra de forma gráfica en la Fig. 2. Consta de tres etapas principales: CARGA, EXECUCIÓN y CONSULTA. La primera etapa comprende la construcción de un repositorio de páginas web mediante un crawler web. Inicialmente el crawler web se inicializa con un conjunto de URLs semilla. A partir de este conjunto pequeño, el crawler web recupera nuevas páginas web y construye un repositorio local almacenado como un archivo XML que contiene solo aquellas URLs de páginas web con formularios HTML (posibles ICWs) y descarta aquellas URLs relacionadas a información estática, tal como documentos (archivos con extensión .PDF, .DOC, etc.) o imágenes (archivos con extensiones .JPG, .GIF, etc.)

La segunda etapa de EJECUCIÓN consta de los tres módulos necesarios para la construcción de la herramienta de búsqueda vertical:

- un detector automático de ICWs, - un clasificador automático de ICWs - un integrador automático de ICWs.

A partir del repositorio de URLs construido en la etapa de CARGA, la etapa de EJECUCIÓN es responsable de recuperar, analizar y manipular las páginas web para descubrir

y extraer ICWs a través del detector automático de ICWs. Una vez que las ICWs son identificadas independientemente de su dominio, el clasificador automático de ICWs determina y selecciona solo aquellas ICWs que pertenecen al dominio seleccionado de interés. En este trabajo el contenido visual de cada ICW es representado mediante un modelador jerárquico que explota la información proporcionada por el árbol de renderizado de cada ICW. Cada ICW se modela como un esquema visual de árbol (AEV). El conjunto de AEVs se envía al integrador automático para la construcción de un esquema unificado que permite crear el formulario HTML de la ICW unificada. Bajo el modelo jerárquico propuesto se preservan las relaciones padre-hijo presentes en los esquemas jerárquicos individuales de cada ICW.

Finalmente en la tercera etapa de CONSULTA, una interfaz gráfica de usuario es responsable por invocar y desplegar la ICW unificada construida a partir del integrador automático de ICWs. Esta ICW unificada permite a los usuarios enviar consultas transparentemente a diferentes ICWs, así como recuperar e integrar la información retornada a partir de las diferentes bases de datos web. Una vez que un usuario envía una consulta a través de la ICW unificada, internamente esta se comunica con un mediador (módulo de software que soporta vistas integradas a través de múltiples fuentes y crea una capa de aplicaciones), que tiene la función de generar una conexión individual con cada ICW y recoger los resultados obtenidos por las mismas.

Figura 2. Representación gráfica de la metodología propuesta para construir herramientas de búsqueda vertical.

Los resultados obtenidos por el mediador son encapsulados

y enviados como respuesta final a la interfaz de usuario. El mediador tiene una interacción directa con cada ICW individual. Este provee acceso a datos a partir de diferentes


fuentes usando un modelo común de datos y un lenguaje de consulta común. El mediador recibe la consulta a partir de la ICW unificada, transforma y transfiere la consulta en una que sea comprensible por la fuente de información (original ICW) en un formato apropiado, por ejemplo <fuente, acción, atributos={a1=v1, a2=v2,… , an=vn }>, donde la fuente corresponde a la URL de la ICW individual, la acción específica donde enviar los datos formateados cuando una consulta es enviada y los atributos contienen los valores de dominio capturados en la consulta. Los resultados obtenidos de las consultas web enviadas a las bases de datos web son ordenados y presentados de acuerdo con la métrica de reputación PageRank de Google de las páginas web que contienen las ICWs individuales consultadas. La consulta enviada por el usuario es un proceso que ocurre en línea. Aunque, VSearch se puede implementar en una PC personal, el diseño de VSearch permite su implementación en varias PCs conectadas por una red en un clúster.

IV. DETECTOR Y CLASIFICADOR AUTOMÁTICO DE

ICWS Este trabajo utiliza el enfoque de pre-consulta propuesto en

[20] para la detección de ICWs en páginas web durante la etapa de EJECUCION. Sin embargo, la estrategia propuesta en [20] fue adaptada para proveer las interfaces de entra y salida necesarias a ser integradas al flujo de procesamiento en la etapa de EJECUCIÓN (Fig. 2). La entrada al identificador automático de ICWs es una lista L de n URLs con posibles ICWs a ser identificadas y la salida es una lista LICW de formularios HTML clasificados como ICWs.

Por otro lado, el clasificador automático de ICWs (Fig. 2) tiene la función de determinar el dominio de cada una de las ICWs dadas. Este trabajo implementa como clasificador automático de ICWs la estrategia reportada en [19], incorporando las correspondientes interfaces de entrada y de salida para que dicho módulo pueda ser incluido apropiadamente en la etapa de EJECUCIÓN (Fig. 2). La entrada al clasificador es la lista resultante del detector de ICWs LICW junto con el dominio de interés D. Como salida, ofrece la lista de ICWs LD = {I1, I2,..., In} tal que Ij en LICW pertenecen al dominio D.

V. INTEGRADOR AUTOMÁTICO DE ICWS

El integrador tiene como objetivo, a partir de un conjunto de ICWs del mismo dominio, con variedad de cobertura y capacidades de consulta, construir una ICW unificada que preserve las relaciones ancestro-sucesor de los componentes individuales de las ICWs. Al mismo tiempo, el integrador de ICWs mantiene las restricciones de agrupamiento entre campos tanto como sea posible. La construcción de la ICW unificada para un dominio dado, implica las siguientes tareas:

1. Extracción y modelado de ICWs 2. Cálculo de relaciones semánticas entre campos de

diferentes ICWs en el mismo dominio 3. Construcción de la ICW unificada 4. Envío de una consulta global a través de la ICW

unificada a cada ICW individual

En este trabajo el proceso de integración de ICWs es

dividido en cuatro fases: a) modelado jerárquico de ICWs; b) clustering de campos de ICWs; c) homogenización de campos y d) unificación de esquemas homogéneos.

A. MODELADO JERÁRQUICO DE ICWS

Definición 1. Modelado de ICWs: es la representación lógica de la estructura interna de una ICW con el objetivo de encontrar consultas implicadas en componentes lógicamente relacionados, conocidos como segmentos.

Definición 2. Motor de renderizado: componente típicamente embebido en los navegadores web, clientes e-mail, lectores de libros electrónicos u otras aplicaciones que requieren la visualización (y edición) de contenido web.

Definición 3 Árbol de renderizado: estructura jerárquica creada por un motor de renderizado y conformado por la descripción de contenido marcado (HTML, XML, etc.) e información de formato (CSS, XSL, etc.) [16].

El modelo jerárquico de una ICW permite tener una vista simplificada, abstracta y fácilmente comprensible de su contenido, recuperando y mostrando los componentes de la ICW en una forma ordenada e independiente. Este modelo representa a una ICW como una estructura jerárquicamente organizada, donde sus componentes mantienen un orden espacial. Es decir, los campos que están relacionados semánticamente usualmente están agrupados juntos en una ICW. Además, este modelo describe las relaciones semánticas y las restricciones de agrupación entre los componentes de una ICW. Por ejemplo, en la Fig. 3 b), el modelo jerárquico muestra la siguiente información: 13 campos, 4 grupos y 1 super-grupo. Ciertos campos tienen asociado etiquetas tales como "Language" que se asigna al campo check-list teniendo como valor de dominio "Any language".

En un modelo jerárquico, un grupo es un conjunto de campos hermanos que comparten el mismo padre. Por ejemplo, en la Fig. 3 b), las etiquetas "Price Range” y “Publication Year” definen dos grupos. En esa misma figura se distingue el super-grupo etiquetado como “Narrow your search criteria”. Todos los componentes en las ICWs permiten un agrupamiento natural de componentes visuales que conduce a una representación jerárquica de ellos.

Aunque el árbol de renderizado de una ICW usado por el modelador jerárquico es no etiquetado, complejo y desorganizado, este proporciona la información necesaria que permite la construcción del modelo visual comprensible de una ICW. Para lograr esto, inicialmente se aplicó una etapa de pre-procesamiento al árbol de renderizado, removiendo nodos con meta-datos innecesarios, tales como, información de estilo (tipo de letra, tamaño de fuente, color de fuente, etc.), información de formato (td, div, br), y otra información adicional o información multimedia que no es de interés para el proceso de modelado. Lo que resulta de interés en el árbol de renderizado es la información estructural y geométrica (anchura, altura y posición de los componentes) de la vista de la ICW. La información geométrica permite explotar las relaciones espaciales (arriba, abajo, izquierda, derecha,


contener, superposición y disjuntos) que existen entre los componentes del árbol. Estas relaciones espaciales se utilizan para determinar la relación entre cada par de nodos en el árbol de renderizado, por ejemplo, la relación de pertenencia (si el nodo ni está contenido en otro nodo nj); intersección (dos nodos hermanos con el mismo padre y la misma profundidad); disjuntos (si dos nodos en el árbol no comparten el mismo padre común), etc.

a)EjemplodeunaICWdeldominiodeLibros

Root

EnterYourSearchTerms:

NarrowYourSearchCriteria:

Title Author Subject Keyword ISBN

Sortyourresultsbelow:

Binding Language

PriceRange PublicationYear

PublisherMethod from to after before

Super-Grupo

Grupos

NodosHoja

b)ModelodelaICWdea)

Figura 3. Ejemplo del contenido visual de una ICW en el dominio de “Libros”.

La etapa de pre-procesamiento produce una versión podada del árbol de renderizado original, más simple y con información útil para la construcción de esquemas jerárquicos AEVs. La construcción de un AEV es guiada por solo 5 de 8 reglas heurísticas descritas en [18] que se definen sobre la estructura del árbol de renderizado podado. Las reglas 3, 7 y 8 reportadas en [18] son innecesarias debido a que estas no proporcionan suficiente información acerca de las relaciones espaciales existentes entre cada par de nodos en el árbol de renderizado podado.

B. CLUSTERING DE CAMPOS DE LAS ICWS

Una vez que los esquemas AEV son construidos, la segunda fase en el proceso de integración automática de ICWs consiste en identificar relaciones semánticas entre campos o nodos hoja en los esquemas AEV y grupos de campos o nodos internos de acuerdo a su similitud. Para el clustering de campos se diseñó un algoritmo de extracción de campos que recorre recursivamente los esquemas AEV e identifica y almacena información de los nodos visitados (nodos hoja e internos) dentro de un vector de nodos V. Este vector almacena por cada nodo la siguiente información: identificador del nodo, número de nodo, etiqueta del nodo, nombre del nodo (si existe), tipo de nodo (nodo hoja, nodo compuesto, nodo interno), nodo padre (si existe) y la lista de nodos hijos T={n1,n2,…nm} (si existen). Entonces, se aplica un

pre-procesamiento a cada etiqueta de texto asociada a los nodos almacenados en V. Ese procesamiento consiste en la eliminación de palabras vacías (stop-words), normalización de etiquetas aplicando un proceso de lematización (stemming) y obteniendo conceptos sinónimos de las etiquetas usando WordNet.

El siguiente paso en el clustering de campos es el cálculo

de relaciones semánticas simples y complejas entre los nodos del vector V. En el caso de relaciones semánticas simples 1:1 entre los campos o nodos hoja, estas son agrupadas de acuerdo a su similitud semántica usando un algoritmo de clustering jerárquico aglomerativo. La similitud semántica entre dos campos se calcula como la suma de la similitud lingüística más la similitud de dominio [22]. La similitud lingüística mide la similitud que existe entre las etiquetas de campo y sus nombres, así como una combinación entre las etiquetas y los nombres. Por otro lado, la similitud de dominio determina si los campos tienen el mismo tipo y valores de dominio. El Algoritmo 1 calcula la similitud semántica entre dos campos. El algoritmo recibe como entrada dos campos y calcula su similitud lingüística como la suma de la similitud entre etiquetas de campo, nombres de campos y la combinación de ellos usando la función coseno.

Las variables αn, αl, y αln, en el algoritmo son tres coeficientes de peso, reflejando la importancia relativa de la similitud lingüística. En este algoritmo maxSimilarity, representa el umbral deseado para determinar la similitud máxima entre todos los pares de valores del dominio. Entrada: ti: campo1, tj: campo2

1. 𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛 𝑡𝑡! , 𝑡𝑡! = 𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶 𝑡𝑡! .𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁 , 𝑡𝑡! .𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁 ;

2. 𝑙𝑙𝑙𝑙𝑙𝑙𝑙𝑙 𝑡𝑡! , 𝑡𝑡! = 𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶 𝑡𝑡! .𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸 , 𝑡𝑡! .𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸 ;

3. 𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛 𝑡𝑡! , 𝑡𝑡! = 𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶 𝑡𝑡! .𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁 , 𝑡𝑡! .𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸 ;

4. 𝑙𝑙𝑙𝑙𝑙𝑙𝑙𝑙𝑙𝑙 𝑡𝑡! , 𝑡𝑡! = 𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶 𝑡𝑡! .𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸 , 𝑡𝑡! .𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁 ; 5. 𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠 = 𝛼𝛼! ∗ 𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛 𝑡𝑡! , 𝑡𝑡! + 𝛼𝛼! ∗ 𝑙𝑙𝑙𝑙𝑙𝑙𝑙𝑙 𝑡𝑡! , 𝑡𝑡! + 𝛼𝛼!" ∗ 𝑚𝑚𝑚𝑚𝑚𝑚 𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛 𝑡𝑡! , 𝑡𝑡! , 𝑙𝑙𝑙𝑙𝑙𝑙𝑙𝑙𝑙𝑙 𝑡𝑡! , 𝑡𝑡!

6. 𝑡𝑡𝑡𝑡𝑡𝑡𝑡𝑡𝑡𝑡𝑡𝑡𝑡𝑡 𝑡𝑡! , 𝑡𝑡! = 1 𝑠𝑠𝑠𝑠 𝑡𝑡𝑡𝑡𝑡𝑡𝑡𝑡 𝑡𝑡! = 𝑡𝑡𝑡𝑡𝑡𝑡𝑡𝑡(𝑡𝑡!)0 𝑒𝑒𝑒𝑒 𝑜𝑜𝑜𝑜𝑜𝑜𝑜𝑜 𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐

donde tipo=time,date,

int,money,string, month, boolean

7. 𝑡𝑡! = 𝑑𝑑!,𝑑𝑑!,… ,𝑑𝑑! //valores de dominio de ti 8. 𝑡𝑡! = 𝑒𝑒!, 𝑒𝑒!,… , 𝑒𝑒! // valores de dominio de tj 9. Para j=1 hasta n hacer 10. Para i=1 hasta m hacer 11. 𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶 𝑡𝑡! , 𝑡𝑡! = !!∙!!

!!∗!!

12. Si 𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶 𝑡𝑡! , 𝑡𝑡! < 𝑚𝑚𝑚𝑚𝑚𝑚𝑚𝑚𝑚𝑚𝑚𝑚𝑚𝑚𝑚𝑚𝑚𝑚𝑚𝑚𝑚𝑚𝑚𝑚 entonces 13. C=C+1 14. End Si 15. End Para 16. End Para 17. 𝑣𝑣𝑣𝑣𝑣𝑣𝑣𝑣𝑣𝑣𝑣𝑣𝑣𝑣𝑣𝑣 𝑡𝑡! , 𝑡𝑡! = !∗ !

!!!!!

18. 𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑 𝑡𝑡𝑖𝑖, 𝑡𝑡𝑗𝑗 = 𝛼𝛼! ∗ 𝑡𝑡𝑡𝑡𝑡𝑡𝑡𝑡𝑡𝑡𝑡𝑡𝑡𝑡 𝑡𝑡! , 𝑡𝑡! + 𝛼𝛼! ∗ 𝑣𝑣𝑣𝑣𝑣𝑣𝑣𝑣𝑣𝑣𝑣𝑣𝑣𝑣𝑣𝑣 𝑡𝑡𝑖𝑖, 𝑡𝑡𝑗𝑗 19. 𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠 𝑡𝑡𝑖𝑖, 𝑡𝑡𝑗𝑗 = 𝛼𝛼!" ∗ 𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠 𝑡𝑡! , 𝑡𝑡! + 𝛼𝛼!" ∗ 𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑 𝑡𝑡𝑖𝑖, 𝑡𝑡𝑗𝑗 Regresa similitud

Algoritmo 1. Similitud semántica de dos campos


Una vez que se calcula la similitud lingüística entre dos campos, la similitud de dominio se determina como la suma de la similitud de los tipos tipoSim y la similitud de los valores de dominio valorSim. Los tipos considerados son: time, money, calendar month, numerical and string.

La función de Dice [4] se utilizó para medir el porcentaje del rango de superposición (overlapping) de los valores de dominio. Esta función esta basada en el coeficiente Dice [3], que considera el número de características de dos valores de dominios que tienen afinidad, multiplicado por dos, sobre el número total de características.

Por otro lado, en el caso de las relaciones complejas entre campos del tipo 1:m, las siguientes consideraciones son tomadas en cuenta:

- Identificación de campos compuestos en diferentes ICWs usando delimitadores tales como </,_ , ; , &> o palabras clave tales como “and”, ”with”, “mm/dd/yyyy”, las cuales son las más comúnmente usadas.

- Identificación de etiquetas de grupo para todos los campos que comparten el mismo padre.

- Estimación de la similitud entre una etiqueta de grupo y un campo compuesto m

- Verificación de la correspondencia 1:1 entre cada subdominio de un campo compuesto m y el dominio de algún campo f.

- Los campos representados por una etiqueta de grupo lg y el campo compuesto con la etiqueta lc serán considerados parte del mismo cluster si lg y lc son altamente similares.

Cuando el proceso de clustering termina, cada cluster es etiquetado con la etiqueta que tiene la mayor frecuencia de ocurrencia de todas las etiquetas de los campos en el cluster ci. El resultado de la etapa de clustering de campos es una partición de V, tal que sólo campos similares están en el mismo cluster y tienen una etiqueta representativa.

C. HOMOGENIZACIÓN DE CAMPOS

La homogenización de campos en el integrador automático de ICWs asigna el mismo identificador a los nodos o los campos que aparecen en diferentes esquemas AEV que tienen el mismo significado. La homogenización de campos hace que el proceso de unificación de esquemas AEV sea más fácil. El Algoritmo 2 describe el proceso de homogenización. Este algoritmo toma como entrada los esquemas AEV de cada ICW y la lista de clusters de campo LC = {c1, c2, c3, · · ·, cn} construida en las fases anteriores. Para cada cluster etiquetado ci ∈ LC, se obtiene el número de ICW y el identificador de campo para poder hacer referencia al campo al campo a ser homogenizado en una ICW dada. Por simplicidad, el identificador representante de cada cluster ci es reemplazado por un símbolo. Se utiliza un mapeo xRy para asociar el símbolo y al identificador x. R asigna la secuencia de símbolos a, b, c, · · · para cada identificador x1, x2, x3, ··· correspondiente a cada clúster c1, c2, c3, · · ·. El símbolo y para el identificador x del clúster ci se utiliza como la nueva etiqueta de cada campo fi en ci.

Entrada: clusters, árboles 1. EtiquetadoClusters(clusters); 2. conjuntoClaves ← clusters.ConjuntoClave(); 3. Para cada clave ∈ conjuntoClaves hacer 4. cluster ← cluster.obtener (clave); 5. nuevaEtiqueta ← clave; 6. Para cada nodo ∈ cluster hacer 7. numICW ← nodo.obtenerICW (); 8. numNodo ← nodo.obtenerNumNodo(); 9. idCluster ← Mapear.nuevaEntrada(nuevaEtiqueta); 10. AEVi ← obtenerAEV (numICW); 11. árbol.renombrarNodo(numNodo, idCluster); 12. Fin para 13. Fin para Regresa lista de AEVs Algoritmo 2. Homogenización de campos

D. UNIFICACIÓN DE AEVS HOMOGÉNEOS

La última fase del integrador automático de ICWs

correspondiente a la unificación de AEVs homogéneos. Esta fase involucra varias operaciones sobre el conjunto de AEVs en su representación matricial, preservando tanto como sea posible, las relaciones ancestro-sucesores en cada AEV individual dentro del AEV unificado. La fase de unificación toma como entrada AEVs homogéneos y transforma estos esquemas en su respectiva representación matricial para manipular fácilmente los nodos en cada esquema y aplicar operaciones sobre ellos. Al igual que en [17], los AEVs se transforman en su representación de matriz de restricción y un conjunto de transformaciones se aplican para la construcción de un AEV promedio unificado, que representa el centro de la distribución de datos. Sin embargo, a diferencia de [17], los esquemas jerárquicos AEVs a integrarse se construyen de forma automática utilizando el modelador jerárquico propuesto en este trabajo.

El vector de distancia de los nodos ancestro de todos los nodos de los esquemas AEVs se obtiene para construir la matriz de restricción de cada AEV. En el esquema AEV, la distancia entre dos campos diferentes, a y b es la longitud de la trayectoria más corta entre ellos, que se denota como dis (a, b), donde el peso de cada arista en el AEV es de 1. Del mismo modo, la distancia entre un campo a y el nodo raíz (root) se define como la longitud de la ruta más corta desde el nodo raíz al campo a, denominada profundidad/nivel del campo a. Por lo tanto, la matriz de restricción CM de un esquema AEV se construye si y sólo si cada elemento en la matriz de restricción satisface la Ecuación 1.

𝐶𝐶𝐶𝐶[𝑖𝑖, 𝑗𝑗] = 𝑑𝑑𝑑𝑑𝑑𝑑 𝑖𝑖, 𝑗𝑗 𝑠𝑠𝑠𝑠 𝑖𝑖 ≠ 𝑗𝑗

𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝 𝑖𝑖 𝑒𝑒𝑒𝑒 𝑜𝑜𝑜𝑜𝑜𝑜𝑜𝑜 𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐 (1)

La Fig. 4 muestra un ejemplo de un esquema AEV

homogéneo con 13 nodos hoja correspondiente a los 13 campos en la ICW mostrada en la Fig. 4 a). La matriz de restricción de tamaño 13x13 se muestra en la Fig. 4 c). En esta


matriz la intersección entre el elemento a en el renglón 1 y el elemento f en la columna 3 corresponde a la distancia más corta entre ellos, dis(a,f)=4 en el AEV, y la intersección del elemento a consigo mismo corresponde a la distancia entre el nodo raíz (root) del esquema AEV y el nodo a denotado como profundidad(a)=2.

VectordePrecedencia

c)MatrizdeRestricción

Root

Author

gMethod

EnterYourSearchTerms:

Binding Language

h

NarrowYourSearchCriteria:

PriceRange

PublicationYear

from

b)EsquemaVR-Tree

a) b) c)

Title KeywordSubject ISBN

Sortyourresultsbelow:

to beforeafter Publisher

abcde f ij kl m

Figura 4. Ejemplo la matriz de restricción. a) Segmento de una ICW; b) AEV homogenizado correspondiente a la ICW de a); c) Matriz de restricción correspondiente a b)

Para calcular la distancia entre los nodos a y b a partir de su ancestro común se usa el algoritmo DFS (Búsqueda Primero en profundidad). Una vez que las matrices de restricción se obtienen para cada esquema AEV, el siguiente paso consiste en obtener el vector de precedencia para cada esquema. La precedencia de nodos es de izquierda a derecha (Fig. 4 c), considerando sólo los nodos hoja. El vector de precedencia contiene una secuencia ordenada de los n campos de un AEV T. Este vector se define como V = [V1, V2, · · ·, Vi, · · ·], donde cada Vi se calcula utilizando la Ecuación 2.

𝑉𝑉! =!"#(!! )!! 𝑠𝑠𝑠𝑠 𝑓𝑓! ∈ 𝑠𝑠!"#𝑠𝑠 ≠ 𝑗𝑗

𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝 𝑖𝑖 𝑒𝑒𝑒𝑒 𝑜𝑜𝑜𝑜𝑜𝑜𝑜𝑜 𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐 (2)

Donde pos(fi) representa la posición del campo fi de

izquierda a derecha en la secuencia Sect, y m' representa el número de campos de un esquema AEV T. Por ejemplo, si cuatro ICWs, ICW1, ICW2, ICW3, ICW4 están siendo integradas, y existen cinco campos diferentes en las cuatro ICWs, f1, f2, f3, f4 y f5, entonces, asumiendo que para la ICW1 su AEV T1 tiene tres de estos cinco campos (m' = 3) con la secuencia SECT1 = {f5, f2, f1}, el vector de precedencia VT1

calculado con la Ecuación 2 será 1, !!, 0,0, !

!.

Después de calcular la matriz de restricción junto con el vector de precedencia de cada esquema AEV, el siguiente paso es calcular la matriz promedio avgM de todas las matrices de restricción y el vector promedio avgVect de los vectores de precedencia obtenidos de cada AEV. La matriz promedio es vista como la matriz de restricción esperada, ya que representa el "centro" de la distribución de los campos. La matriz avgM se define como !"! !,!

!!!!! , donde n representa

el número de elementos distintos de cero de las matrices de restricción CM1, CM2,..., CMn. El vector avgVect se define como !"#$! !

!!!!! , donde m representa el número de

elementos distintos de cero en el vector i. A partir de la matriz promedio obtenida avgM, una secuencia de transformaciones se aplican:

La primera transformación consiste en la identificación de

las jerarquías de elementos sobre la diagonal de la matriz de restricción promedio avgM, teniendo en cuenta dos elementos diferentes (atributos) con la distancia> = 2. Estos atributos son redondeados para obtener un valor entero de los niveles que tendrá la matriz unificada. Generalmente, para un esquema de árbol integrado ideal, para cualesquiera dos atributos en un grupo, su distancia en la mayor parte de los esquemas árbol será 2, y su distancia de sólo unos esquemas de árboles será mayor que 2, por ejemplo, 3 o 4.

La segunda transformación sobre la matriz promedio corresponde a la identificación de grupos, considerando sólo aquellos que tienen dos campos con distancia = 2. También para esta transformación, es necesario redondear los componentes que forman parte de los grupos en la matriz avgM.

La tercera transformación tiene como función actualizar la matriz de restricción promedio avgM matriz considerando que los elementos (campos) que pertenecen a un grupo tienen distancia = 2. De lo contrario, la distancia entre ellos debe ser la distancia = profundidad + 1.

La cuarta transformación consiste en la identificación de campos de cada grupo y la unificación de ellos en un único nodo, eliminando campos innecesarios en la matriz de restricción para obtener una matriz reducida.

Finalmente, la quinta transformación consiste en asignar un nombre temporal n1, n2, ..., nj a los nodos internos que contienen el conjunto de nodos de grupo y reemplazarlos en la matriz de restricción.

Después de aplicar estas cinco transformaciones, los dos últimos pasos para construir un esquema AEV unificado son: 1) ordenar la matriz de restricción avgM a partir del vector promedio avgVect, de izquierda a derecha, considerando el valor de los elementos en los nodos internos; 2) convertir la matriz unificada en su esquema de representación de árbol a partir de la matriz de restricción reducida y ordenada. Finalmente, de acuerdo con la estrategia propuesta para el integrador automático de ICWs, el esquema AEV unificado se visualiza en la interfaz gráfica de usuario. En este punto, las etiquetas actuales de los campos en el esquema AEV unificado definidas por símbolos son reemplazadas por las etiquetas originales identificadas durante el proceso de clustering de campos, usando el mapeo (inverso) xRy descrito anteriormente.

VI EVALUACIÓN EXPERIMENTAL

Se construyó un prototipo de una herramienta de búsqueda vertical llamado VSearch para el dominio de Compra de Libros, aplicando la metodología descrita en las secciones anteriores. Se condujeron experimentos con el objetivo principal de demostrar que el enfoque propuesto permite construir, a partir de un conjunto de URLs semilla y de un dominio de interés especificado, una ICW unificada de alta calidad sin la intervención humana, con una precisión alta en el mapeo entre campos para el proceso de integración de ICWs, que permite y facilita al usuario la consulta de diversas bases de datos web relacionadas con el dominio de interés.

A partir de un conjunto de 1025 páginas web (URLs)


construido por un crawler web, se formaron seis subconjuntos de diferentes tamaños (50, 100, 200, 350, 700, y 1025 URLs), seleccionando URLs aleatoriamente. Cada uno de estos subconjuntos fue utilizado para validar y evaluar el flujo completo para la creación de la correspondiente ICW unificada en VSearch. La evaluación de VSearch consiste en medir su desempeño (tiempo de ejecución) y su precisión (para construir la ICW unificada en el proceso de integración).

La Figura 5 muestra la interfaz gráfica de VSearch, la cual permite al usuario ejecutar las siguientes operaciones: a) construir una ICW unificada a partir de un conjunto de URLs semilla. Bajo esta opción, se ejecutan las fases de CARGA y EJECUCIÓN descritas previamente y el modelo AEV de la ICW unificada que se construye se almacena en una memoria secundaria y queda disponible para el usuario en la fase de CONSULTA; b) abrir una ICW unificada (previamente construida y almacenada) para realizar consultas a diversas bases de datos web que dicha ICW unificada representa.

Después de ejecutar las tareas anteriores, el usuario puede utilizar la interfaz gráfica, que se muestra en la Figura 5.

a) Interfaz principal b) ICW integrada para el dominio de libros

Fig. 5 Interfaz gráfica de VSearch VSearch presenta a los usuarios los resultados de la

consulta emitida como una lista de URLs asociadas a las ICWs individuales ordenadas de acuerdo a su reputación expresada como un número en una escala de 0-10 (Fig. 5 b). La reputación de cada URL se obtiene a través de la métrica PageRank de Google. Esta métrica cuenta el número y la calidad de los enlaces a una página o sitio web. La suposición es que los sitios web más importantes son más probables a recibir más enlaces de otros sitios web. El valor de PageRank para cualquier página web a es expresado como la Ecuación 3, para cada página web b contenida en Ba (el conjunto que contiene todas las páginas con enlaces a la página a), dividido por el número de enlaces en b denotado como L(b).

PR(a)= !"(!)

!(!)!∈!! (3)

A. IMPLEMENTACIÓN DE VSEARCH VSearch fue escrito en el lenguaje de programación Java y

probado en una computadora con un procesador Intel Core i3 2.27 GHz, 4 G RAM bajo Windows. VSearch usa un crawler web genérico para construir el repositorio de páginas web en la etapa de CARGA, con posibles ICWs en diferentes dominios. El modelado jerárquico de ICWs utiliza el Lobo Cobra Toolkit para construir los árboles de renderizado de las ICWs a ser consideradas en la ICW unificada.

Todos los datos subyacentes a los resultados reportados en este trabajo se encuentran disponibles y accesibles desde el repositorio público: http://dx.doi.org/10.5281/zenodo. 51959.

B. CRITERIO DE EVALUACIÓN DE VSEARCH

La calidad de un esquema conceptual global puede medirse por tres criterios cualitativos propuestos en [2]: exactitud, integridad y eficiencia. Estos tres criterios se tomaron como base para la evaluación de los esquemas AEV de las ICWs unificadas creadas por VSearch.

Exactitud: Para una ICW dada, su exactitud se define como el porcentaje de campos locales mapeados correctamente entre todos los campos locales. La métrica de exactitud se define en la Ecuación 4, donde Ai representa el número de campos mapeados correctamente en la i-ésima ICW y Bi representa el número total de campos en la i-ésima ICW.

𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸 = !!!

!!!

!!!!!!

(4)

Integridad: Mide las que tan bien son preservadas las capacidades de consulta sobre cada ICW mediante la ICW unificada. Esta medida es definida en la Ecuación 5, donde Ai representa el número de campos en la i-ésima ICW y Yi

representa el número de campos incorrectamente mapeados sobre la i-ésima ICW.

𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼𝐼 = !!!!!!!!!

!!!!!!

(Ec. 5)

Eficiencia: Evalúa el tiempo de ejecución, el esfuerzo o costo en la construcción de la ICW unificada desplegada sobre la interfaz gráfica de usuario de VSearch. El costo de la consulta se considera como el tiempo para la interpretación y ejecución de la consulta.

La Tabla 2 muestra la exactitud, integridad y precisión obtenida por VSearch en la construcción de la ICW unificada para cada conjunto de prueba de URLs. En promedio, la exactitud global e integridad del esquema de la ICW unificada para el dominio seleccionado es de 99,2% y 99,7%, respectivamente.

TABLA 2 EXACTITUD, INTEGRIDAD Y PRECISIÓN DE VSEARCH

# URLs

# ICWs Exactitud (%)

Integridad (%)

Precisión (%)

50 2 100 100 95.6 100 5 100 100 96.3 200 7 98.5 99 92.6 350 15 100 100 95.8


700 36 98.7 99.8 94.0 1025 53 98.3 99.5 93.1

Promedio 99.2 99.7 94.5 La precisión de VSearch se midió con respecto a los

resultados recuperados de las bases de datos web consultadas que se presentan en la interfaz gráfica de usuario. La precisión promedio con los seis subconjuntos es de aproximadamente de 94,5% para el caso de estudio seleccionado. Esto demuestra que el esquema de ICW unificada de VSearch tiene una alta tasa de exactitud e integridad.

C. DESEMPEÑO DE VSEARCH

El desempeño de VSearch se evaluó por el tiempo de ejecución y respuesta de sus componentes. Tal como el detector de ICWs, el clasificador de ICWs, el modelador e integrador de ICWs. El tiempo de ejecución comprende el tiempo transcurrido desde que el repositorio de URLs de páginas web se da al detector de ICWs hasta que el integrador de ICWs construye la ICW unificada. El tiempo de respuesta comprende el tiempo transcurrido desde que el usuario proporciona una consulta específica a través de la ICW unificada hasta que VSearch presenta al usuario los datos resultantes de la ejecución de la consulta en las diferentes bases de datos web.

La Figura 6 a) muestra el tiempo de conexión (tiempo de descarga de páginas web) de VSearch. La figura 6 b) muestra el tiempo de descubrimiento de los formularios HTML en las páginas web, el tiempo de identificación de ICWs, y el tiempo de clasificación de ICWs usando los seis diferentes conjuntos de URLs. Estos tres últimos tiempos son insignificantes en comparación con el tiempo de conexión, el cual es el dominante, con alrededor 2000 segundos para la descarga de 1025 páginas web. Esta situación muestra que más del 90% del tiempo de ejecución de VSearch se consume para la conexión a Internet, la cual depende en gran medida de varios factores como la infraestructura de red, ancho de banda, etc. Sin embargo, ya que este proceso podría ser "off-line", el tiempo de conexión podría ser descartado. La Figura 6 b) muestra que el proceso más demandante en la etapa de EJECUCIÓN de VSearch es el clasificador de ICWs, que consume 13 segundos cuando el conjunto de URLs es de 1025.

Figura 6. Tiempos de VSearch durante las etapas de CARGA y EJECUCIÓN. Un solo hilo de ejecución usando diferentes conjuntos de URLs semilla. A) Tiempo para la descarga de páginas web; b) Tiempo de descubrimiento de formularios HTML asumiendo un proceso “off-line”, tiempo del detector y

clasificador de ICWs

La Figura 7 muestra cómo el tiempo de ejecución que se

muestra en la Figura 6 puede mejorarse después de una aplicación multi-hilo. El tiempo de conexión (en la Fig.7) se reduce drásticamente mediante el uso de un mayor número de hilos de ejecución. Del mismo modo, se observa que el uso de un mayor número de hilos no siempre podría conducir a una reducción del tiempo de ejecución. Por ejemplo, el clasificador de ICWs utiliza un diccionario compartido entre todos los hilos. Un número mayor de hilos implicarán retrasos de sincronización, así como más tiempo empleado para su gestión por el sistema operativo. A través de la experimentación, se pudo determinar un número óptimo de hilos de ejecución, logrando el desempeño más alto.

Figura 7. Tiempos de VSearch durante las etapas de CARGA y EJECUCIÓN. Múltiples hilos de ejecución usando conjuntos de tamaño de 50, 100 y 200 de

URLs semilla. De los resultados presentados en la Figura 7, se puede

afirmar que el tiempo de ejecución por el detector y clasificador de ICWs es razonable, suponiendo que la construcción de una ICW unificada es un proceso que no se ejecuta varias veces.

La Figura 8 muestra el tiempo de ejecución de los tres componentes del integrador automático de ICWs: 1) el modelador jerárquico (AEV), 2) El clustering de campos y 3) la integración de campos, que incluye la homogeneización y unificación de AEVs homogéneos. El modelador jerárquico toma 1.07 segundos para modelar una sola ICW, y hasta 7.34 segundos para modelar cincuenta y tres ICWs. El proceso de clustering (Fig. 8) domina de manera significativa el tiempo de ejecución de la estrategia propuesta para la integración de ICWs debido a las múltiples comparaciones entre los términos


de todas las ICWs involucradas. Requiere 4261 segundos (71.03 minutos) para procesar todos los campos que se encuentran en las 53 ICWs. Esto es esperado, ya que el proceso de clustering utiliza un algoritmo de clustering jerárquico aglomeración con el tiempo de ejecución de O (n3) en el peor de los casos. Sin embargo, este tiempo resulta aún aceptable, considerando que la construcción de una ICW unificada es una tarea que se ejecuta una vez y no exige un tiempo de respuesta crítico.

Este trabajo utiliza hasta 53 ICWs para el proceso de integración, demostrando que VSearch puede manejar un número elevado de ICWs y que es capaz de ejecutar los módulos principales en el proceso de integración (incluyendo el proceso de clustering de campos) en un tiempo aceptable.

Figura 8. Tiempos de ejecución del integrador automático de ICWs en

VSearch.

Desde la perspectiva del usuario, la eficiencia de VSearch

es el tiempo de respuesta, es decir el tiempo transcurrido desde que el usuario envía la consulta a la base de datos web hasta que los resultados de esa consulta están disponibles en la interfaz gráfica. El tiempo de respuesta de VSearch (Fig. 9) toma desde 1.05 segundos con 50 URLs de las páginas web hasta 21.02 segundos usando 1025 URLs. Este tiempo de respuesta tiende a aumentar linealmente en función del número de ICWs correctamente identificadas y clasificadas.

Figura 9. Tiempos de Respuesta de VSearch.

Así, a partir de los resultados descritos, se demuestra la

viabilidad, eficacia y precisión de un prototipo de herramienta de búsqueda vertical que se construye usando la metodología propuesta en este trabajo. Esta metodología sirve como una guía para construir herramientas de búsqueda vertical para otros dominios de interés.

VII CONCLUSIONES El crecimiento explosivo de la información contenida en

bases de datos demanda tener herramientas de búsqueda

vertical que a partir de una ICW unificada permita a los usuarios consultar información en un dominio específico de interés, de manera más simple e integre resultados de diferentes fuentes.

Sin embargo, la construcción automática de una ICW unificada para un dominio dado implica varios desafíos, como los mencionados en este trabajo. A pesar de que existe un número reducido de propuestas para la construcción automática de una ICW unificada, las soluciones actuales sufren limitaciones y en ciertos casos son incompletas.

En este artículo se presentó una metodología para la construcción de herramientas de búsqueda vertical basada en tres componentes principales: el detector, clasificador e integrador automático de ICWs. Sobre este último componente se propuso un nuevo enfoque basado en cuatro componentes: 1) modelado jerárquico de ICWs, 2) Clustering de campos, 3) Homogenización de campos, y 4) Unificación de modelos jerárquicos homogéneos.

Los experimentos conducidos demostraron que la ICW unificada construida por VSearch sin la intervención humana tiene una alta precisión de mapeo de campos en el proceso de integración.

Como trabajo futuro, se plantea mejorar aspectos relacionados a la fase de CONSULTA, para procesamiento, integración, retorno y presentación de los resultados obtenidos por el mediador y la presentación visual al usuario final.

REFERENCIAS

[1] Barbosa, L., Nguyen, H., Nguyen, T., Pinnamaneni, R., Freire, J.: Creating and exploring web form repositories. In: Proceedings of the 2010 international conference on Management of data, SIGMOD ’10, pp. 1175–1178. ACM, New York, NY, USA (2010).

[2] Batini, C., Lenzerini, M., Navathe, S.B.: A comparative analysis of methodologies for database schema integration. ACM Comput. Surv. 18(4), 323–364 (1986).

[3] Castano, S., De Antonellis, V., Fugini, M.G., Pernici, B.: Conceptual schema analysis: Techniques and applications. ACM Trans. Database Syst. 23(3), 286–333 (1998).

[4] Do, H.H., Rahm, E.: Coma: A system for flexible combination of schema matching approaches. In: Proceedings of the 28th International Conference on Very Large Data Bases, VLDB ’02, pp. 610–621. VLDB Endowment (2002).

[5] Dragut, E., Wu, W., Sistla, P., Yu, C., Meng,W.: Merging source query interfaces on web databases. In: Proceedings of the 22Nd International Conference on Data Engineering, ICDE ’06, pp. 46–. IEEE Computer Society, Washington, DC, USA (2006).

[6] Dragut, E.C., Fang, F., Yu, C., Meng, W.: Deriving customized integrated web query interfaces. In: Proceedings of the 2009 IEEE/WIC/ACM International Joint Conference on Web Intelligence and Intelligent Agent Technology - Volume 01, WI-IAT ’09, pp. 685–688. IEEE Computer Society, Washington, DC, USA (2009).

[7] Furche, T., Gottlob, G., Grasso, G., Guo, X., Orsi, G., Schallhart, C.: The ontological key: automatically understanding and integrating forms to access the deep web. The VLDB Journal 22(5), 615–640 (2013).

[8] Dragut, E.C., Meng,W., Yu, C.T.: Deep Web Query Interface Understanding and Integration. Synthesis Lectures on Data Management. Morgan & Claypool Publishers (2012).

[9] He, B., Chang, K.C.C.: Automatic complex schema matching across web query interfaces a correlation mining approach. ACM Trans. Database Syst. 31(1), 346–395 (2006).

[10] He, B., Patel, M., Zhang, Z., and Chang, K., Accessing the Deep Web, Commun. ACM, vol. 50, pp. 94--101, New York, NY, USA, (2007).

[11] He, H., Meng, W., Yu, C., Wu, Z.: Automatic integration of web search interfaces with wise-integrator. The VLDB Journal 13(3), 256–273 (2004).


[12] He, H., Meng, W., Yu, C., Wu, Z.: Wise-integrator: a system for extracting and integrating complex web search interfaces of the deep web. In: Proceedings of the 31st international conference on Very large data bases, VLDB ’05, pp. 1314–1317. VLDB Endowment (2005).

[13] He, H., Meng, W., Yu, C.T., Wu, Z.: Wise-integrator: An automatic integrator of web search interfaces for e-commerce. In: VLDB, pp. 357–368 (2003).

[14] Kabisch, T.: Extraction and integration of web query interfaces. Ph.D. thesis (2011).

[15] Kabisch, T., Dragut, E.C., Yu, C., Leser, U.: Deep web integration with visqi. Proc. VLDB Endow. 3(1-2), 1613–1616 (2010).

[16] Kabisch, T., Dragut, E.C., Yu, C.T., Leser, U.: A hierarchical approach to model web query interfaces for web source integration. PVLDB 2(1), 325–336 (2009).

[17] Li, Y., Wang, Y., Jiang, P., Zhang, Z.: Multi-objective optimization integration of query interfaces for the deep web based on attribute constraints. Data and Knowledge Engineering 86, 38–60 (2013).

[18] Marin-Castro, H.M., Sosa-Sosa, V., Lopez-Arevalo, I.: A tree-based wqi modeling approach for integrating web databases. In: 17th International Conference on Information Fusion, FUSION 2014, Salamanca, Spain, July 7-10, 2014, pp. 1–8 (2014).

[19] Marin-Castro, H.M., Sosa-Sosa, V.J., Lopez-Arevalo, I., Escalante-Baldera, H.J.: Automatic classification of web databases using domain-dictionaries. In: Proceedings of the 9th International Conference on Machine Learning and Data Mining in Pattern Recognition, MLDM’13, pp. 340–351. Springer-Verlag, Berlin, Heidelberg (2013).

[20] Marin-Castro, H.M., Sosa-Sosa, V.J., Martinez-Trinidad, J.F., Lopez-Arevalo, I.: Automatic discovery of web query interfaces using machine learning techniques. Journal of Intelligent Information Systems 40(1), 85–108 (2013).

[21] UIUC, T.M.P.: Metaquerier: Exploring and integrating the deep web (2004).

[22] Wu, W., Yu, C., Doan, A., Meng, W.: An interactive clustering-based approach to integrating source query interfaces on the deep web. In: Proceedings of the 2004 ACM SIGMOD international conference on Management of data, SIGMOD ’04, pp. 95–106. ACM, New York, NY, USA (2004).

Heidy M. Marin-Castro, obtuvo el grado de Doctora en Ciencias de la Computación en el Centro de Investigación y de Estudios Avanzados del Instituto Politécnico Nacional (Cinvestav) unidad Tamaulipas, en 2014. Actualmente es

catedrática-CONACYT en la Universidad Autónoma de Tamaulipas. Sus áreas de investigación son minería de datos, gestión de información web y recuperación de información.

Victor J. Sosa-Sosa, es profesor-investigador de tiempo completo en el Laboratorio de Tecnologías de la Información del Cinvestav-Tamaulipas. Obtuvo el grado de Doctor en la Universidad Politécnica de Cataluña, Barcelona. De septiembre de 2012 a julio de 2013 fue investigador visitante en el grupo de sistemas de

información y bases de datos en el Instituto Max Planck de Alemania. Sus áreas de interés y especialización son bases de datos y sistemas distribuidos.

Marco A. Nuno-Maganda, obtuvo el grado de Doctor en Ciencias de la Computación en el Instituto Nacional de Astrofísica Óptica y Electrónica, en 2009. Actualmente es profesor en la maestría en ingeniería de la Universidad Politécnica de Victoria. Sus intereses de investigación son aprendizaje máquina, redes neuronales y visión por

computadora.


574 IEEE LATIN AMERICA TRANSACTIONS, VOL. … · desarrollado en la Universidad de Illinois [21]...

Documents

Transcript of 574 IEEE LATIN AMERICA TRANSACTIONS, VOL. … · desarrollado en la Universidad de Illinois [21]...