Estrategia para Extracción de Datos de MúltiplesFuentes Semi-Estructuradas-Edición Única

Title Estrategia para Extracción de Datos de Múltiples Fuentes Semi-Estructuradas-Edición Única

Issue Date 2006-12-01

Publisher Instituto Tecnológico y de Estudios Superiores de Monterrey

Item Type Tesis de maestría

Downloaded 19/09/2018 09:35:54

Link to Item http://hdl.handle.net/11285/567656

INSTITUTO TECNOLÓGICO Y DE ESTUDIOSSUPERIORES DE MONTERREY

CAMPUS MONTERREY

PROGRAMA DE GRADUADOS EN TECNOLOGÍAS DE INFORMACIÓN Y ELECTRÓNICA

ESTRATEGIA PARA EXTRACCIÓN DE DATOS DE MÚLTIPLESFUENTES SEMI-ESTRUCTURADAS.

TESIS

PRESENTADA COMO REQUISITO PARCIAL PARA OBTENER EL GRADO ACADEMICO DE:

MAESTRO EN MAESTRÍA DE CIENCIAS EN TECNOLOGÍA INFORMÁTICA

POR:

JUAN FERNANDO RIVERA PERNÍA

MONTERREY , N.L. Diciembre de 2006

INSTITUTO TECNOLÓGICO DE ESTUDIOS SUPERIORES DE MONTERREY

DIVISIÓN DE TECNOLOGÍAS DE INFORMACIÓN Y ELECTRÓNICA

PROGRAMA DE GRADUADOS EN TECNOLOGÍAS DE INFORMACIÓN Y ELECTRÓNICA

Los miembros del comité de tesis recomendamos que la presente tesis del Ing. Juan Fernando Rivera Pernía sea aceptada como requisito parcial para obtener el grado académico de Maestro en Ciencias en Tecnología Informática.

Comité de tesis:

______________________________Dr. Juan Carlos Lavariega Jarquín

Asesor

______________________________Dr. Guillermo Jiménez Pérez

Sinodal

______________________________Dra. Lorena Guadalupe Gómez Martínez

Sinodal

_________________________________________Dr. Graciano Dieck Assad

Director del Programa de Graduados en Tecnologías de Información y Electrónica

Diciembre de 2006

ESTRATEGIA PARA EXTRACCIÓN DE DATOS DE MÚLTIPLESFUENTES SEMI-ESTRUCTURADAS.

POR:

JUAN FERNANDO RIVERA PERNÍA

TESIS

Presentada al Programa de Graduados en Tecnologías de Información y Electrónica

Este trabajo es requisito parcial para obtener el grado de Maestro en

MAESTRÍA DE CIENCIAS EN TECNOLOGÍA INFORMÁTICA

INSTITUTO TECNOLÓGICO Y DE ESTUDIOSSUPERIORES DE MONTERREY

Diciembre de 2006

DEDICATORIA

A Dios por darme una vida llena de bendiciones,oportunidades y retos.

A mi familia, mis padres, hermanos y sobrinos, que siempre han estado cerca de mí y motivándome para seguir adelante.

A los amigos, que sin importar la distancia, siempre se alegran cuando se cumplen los sueños.

A ti, lector, porque este trabajo pueda ayudarte en alguna labor que estés realizando.

iv

AGRADECIMIENTOS

Al Dr. Juan Carlos Lavariega por creer en este trabajo

y guiarme con sus consejos y observaciones.

A los doctores Guillermo Jiménez y Lorena Gómez por sus

sugerencias y aportaciones.

A mis compañeros de maestría y del trabajo que siempre fueron fuente de motivación.

Al Instituto por proporcionarme un reto que cumpliry una oportunidad para superación.

Gracias.

v

RESUMEN

En la época actual, se vive una época donde una de las fuentes de información más importante es el World Wide Web, donde el formato primordial para documentos de información es el lenguaje HTML, que despliega información, que en ocasiones se requiere almacenar en un medio digital como una base de datos.

De esta fuente de información en ocasiones se desea extraer información de los documentos HTML existentes en el World Wide Web, para almacenar esa información en una base de datos para usarla en explotación de datos para distintas aplicaciones futuras, pero en los documentos no se encuentra esa estructura.

Es por ello que el presente trabajo de tesis, presenta una serie de pasos para extraer datos de documentos HTML referentes a un área de conocimiento, donde estos pasos pueden aplicarse en distintos documentos que traten la misma área de conocimiento.

Para ello, se analizó la forma de detectar elementos de datos en documentos HTML, y distinguirlos de aquellos que describen la forma de presentarlos, para alimentar una base de datos, reduciendo el tiempo de alimentación de la misma.

La información extraída puede utilizarse para aplicaciones de minería de datos para detectar o predecir tendencias.

Tomando lo anterior como base para la elaboración del producto final, una estrategia para extracción de datos expuesta en esta tesis.

vi

TABLA DE CONTENIDOS

DEDICATORIA ivAGRADECIMIENTOS vRESUMEN viTABLA DE CONTENIDOS viiTABLA DE IMÁGENES ixCapítulo 1. Introducción 1

1.1 Antecedentes 51.2 Objetivo 61.3 Situación Problemática 71.4 Hipótesis 91.5 Alcance 101.6 Justificación 101.7 Resultados Esperados 11

Capítulo 2. Fundamentos técnicos y tecnológicos 132.1 Marco teórico 132.2 Trabajos sobre extracción de datos 14

2.2.1 Búsqueda de cambios en datos semi-estructurados 142.2.2 Transformación a documento bien formado 152.2.3 Extracción de datos de páginas Web 162.2.4 Estructura de búsqueda por dominio 172.2.5 Estructuras similares 182.2.6 Estrategia “Dividir y Vencer” 192.2.7 Extracción de datos usando XML 212.2.8 Modelo de búsqueda de información ANDES 222.2.9 Really Simple Syndication 22

2.3 Conceptos 232.4 Integración de datos 252.5 Conclusiones 27

Capítulo 3. Fundamentos de la Extracción de Datos 293.1 Extracción de datos 293.2 Propuesta de la estrategia 313.3 Definición de estructura de Búsqueda 323.4 Fuente de Datos 38

3.4.1 Seguimiento en el tiempo de una misma fuente 393.4.2 Búsqueda de información en distintas fuentes 40

3.5 Transformación de página de red 413.6 Puntos de referencia 44

3.6.1 Búsqueda de cada elemento 45

vii

3.6.2 Buscar cada palabra de los tags 463.6.3 Mapeo de puntos de referencia a la estructura de datos 46

3.7 Conclusiones 48Capítulo 4. Casos Prácticos 49

4.1 Captura semi-automatizada de una fuente de datos 494.1.1 Definición de estructura de búsqueda 504.1.2 Fuente de Datos 504.1.3 Transformación de página de red 504.1.4 Puntos de referencia 554.1.5 Copiado de información a la base de datos 584.1.6 Comparativo con segunda fuente de datos 594.1.7 Observaciones del caso práctico 61

4.2 Seguimiento en el tiempo de una fuente de información 624.2.1 Definición de la estructura de búsqueda 634.2.2 Fuente de datos 634.2.3 Transformación de página de red 654.2.4 Puntos de referencia 664.2.5 Copiado de información a la base de datos 674.2.6 Observaciones del caso práctico 67

4.3 Conclusiones 68Capítulo 5. Aportaciones y Trabajo Futuro 70

5.1 Aportaciones 705.1.1 Estrategia genérica de extracción de datos 705.1.2 Reducción en tiempo de alimentación de base de datos 715.1.3 Seguimiento en el tiempo de una fuente de datos 72

5.2 Trabajos Futuros 725.2.1 Manejo de elementos desconocidos 725.2.2 Minado por seguimiento de páginas 735.2.3 Interacción con sistemas expertos 745.2.4 Disminución de intervención humana en el proceso 755.2.5 Agentes Inteligentes 76

5.3 Aplicaciones 775.3.1 Extracción de datos específicos de monitoreo de bases de datos 775.3.2 Aplicaciones de seguimiento de datos. 78

5.4 Conclusiones 79Capítulo 6. Conclusiones del trabajo 80REFERENCIAS BIBLIOGRÁFICAS 82Apéndice: Estructuras XML de datos de beisbol. 85VITA 91

viii

TABLA DE IMÁGENES

Figura 1.1. Propuesta básica de la estrategia. 2Figura 1.2. Estilo común de presentar resultados de partidos de fútbol. 3Figura 1.3. Estilo FIFA de representar partidos de fútbol 4Figura 3.1. Flujo del proceso. 30Figura 3.2. Proposición de la estrategia. 31Figura 3.3. Ejemplo de partidos de fútbol 36Figura 3.4. Formato del sitio www.mundosoccer.com antes de septiembre del 2006 37Figura 3.5. Formato del sitio www.mundosoccer.com a partir de septiembre del 2006. 37Figura 4.1. Datos de bateador de béisbol. 51Figura 4.2. Datos de lanzador de béisbol 54Figura 4.3. Imagen del sitio www.baseball-reference.com 60Figura 4.4. Reporte de clima de la página weather.cnn.com 64

ix

Capítulo 1. Introducción

El crecimiento del World Wide Web en los últimos años lo ha convertido en la fuente de información más rica y densa que el mundo ha visto [1], sin embargo la mayor parte de esta información se encuentra ordenada de una forma visual, mas no necesariamente en una estructura de datos lógica, lo cual puede verse como un problema si se desea utilizar esta información con aplicaciones que requieran una estructura de datos lógica.

En particular, la difusión y utilización del lenguaje HTML es un fenómeno, dicho lenguaje es en la actualidad el principal medio para visualizar la información existente en el World Wide Web por las facilidades que otorga para la presentación de la misma hacia un ser humano, pero al realizar aplicaciones cuyo fin sea el acceso de datos se encuentran dificultades para dicho acceso, ya que no es objetivo del lenguaje; por ende, cualquier software que pretenda realizar procesos de automatización al acceso de datos contenidos en páginas escritas en lenguaje HTML lidiará con este problema. Entendemos por automatización al acceso de datos a un proceso realizado por un software para realizar determinadas acciones específicas. Dicha automatización se complica debido a la flexibilidad que caracteriza al lenguaje HTML al permitir a los creadores de páginas mostrar la misma información de distintas formas, que si bien se considera una ventaja del lenguaje el hecho de vislumbrar los mismos elementos de un dominio de datos de distintas formas, a la hora de aplicar un proceso de automatización puede presentar problemas para manejar dichos elementos. Como muestra, el órden en que se muestran los mismos elementos de información, varia entre distintas páginas HTML.

Por lo tanto, dada la existencia de múltiples fuentes de información tratantes del mismo tema, es poco probable que dicha información se presente de la misma forma, aunque el área de conocimiento y los tipos de datos presentados sean los mismos. En gran medida esto se debe a que un mismo tema es abordado por diferentes creadores de páginas, los cuales definen diferentes formas de presentar la misma información. Un ejemplo muy sencillo son los resultados de una jornada en un torneo de futbol, una página puede mostrar los resultados en forma tabular de una jornada, mientras otra va llenando una matriz de juegos entre todos

1

los participantes. En ambas páginas HTML los elementos son los mismos: un conjunto de partidos entre dos equipos deportivos que tiene un marcador indicando el resultado del encuentro. Un observador puede determinar el marcador del último partido del equipo interesado en ambos casos pues la información es la misma, localizable para el aficionado que conoce la estructura del resultado de un partido de futbol. Es factible pensar en una forma de automatizar la búsqueda de información en páginas HTML sobre un tema ya que siempre existen elementos de información que permiten interpretar dicho tema.

El presente trabajo aborda esta situación definiendo la problemática como la extracción de información de una estructura de datos con elementos de un dominio de datos sobre una o más fuentes de información. El núcleo de este trabajo radica en la estructuración de la estructura de datos y el llenado de dicha estructura, aun cuando las fuentes de información no necesariamente poseen una estructura de datos definida. La figura 1.1 presenta un panorama genérico de la estrategia a seguir en este trabajo:

Figura 1.1. Propuesta básica de la estrategia.

2

La propuesta en este trabajo es una estrategia para manejar situaciones donde se busca extraer información referente a un área de conocimiento específica, donde dicha información puede radicar en distintos documentos HTML u otras fuentes de información1 y a su vez, no se encuentra estructurada de la misma forma en cada una de las fuentes. Supongamos la creación y alimentación de un catálogo de una determinada área de conocimiento, por ejemplo, un catálogo de torneos de fútbol soccer.

Un torneo de fútbol soccer consiste de uno o más partidos que se disputan en más de una fase y eventualmente se obtiene un campeón. De igual forma, cada partido consiste de un equipo local que anota una cantidad finita de goles y un equipo rival, llamado visitante, que anota otra cantidad finita de goles. El resultado de dicho partido, si un equipo ganó, o si hay empate se determina en base a la diferencia entre los goles anotados por el equipo local contra los goles anotados por el equipo visitante. Se observa que la estructura de datos es la misma para cualquier torneo de fútbol soccer donde solo interesa guardar la información relevante a los partidos. No obstante dicha estructura puede mostrarse de distinta forma en distintas fuentes, como se ve en los siguientes ejemplos:

Figura 1.2. Estilo común de presentar resultados de partidos de fútbol.

1 Estas fuentes de información pueden presentarse en otros formatos, sin embargo, en la actualidad, casi cualquier formato puede convertise a un equivalente en HTML. Esto se aborda con mayor detalle en los capítulos 3 y 4.

3

Figura 1.3. Estilo FIFA de representar partidos de fútbol

En ambos casos, las estructuras reflejan los mismos marcadores, no obstante, los documentos HTML finales la muestran de manera diferente, un programa que busque la información indicada en la figura1.2, presenta los resultados en el formato “Equipo_Local Marcador_Local – Marcador_Visitante Equipo_Visitante” no funcionará al buscar en la fuente que presente la información como en la figura 1.3, donde aparece como “Equipo_Local:Equipo_Visitante Marcador_Local:Marcador_Visitante”. Por ejemplo, el primer partido se interpreta que Alemania derrotó a Costa Rica por marcador de 4 goles a 2.

La solución propuesta para este caso, que se plantea en este trabajo es una estrategia que permita extraer datos de documentos HTML. Los datos estarían definidos y delimitados por una estructura de datos, proponiendo que la definición de esta estructura sea en lenguaje XML. Hay varias aplicaciones propuestas:

1) Seguimiento de datos, en el tiempo y en diversas fuentes. Con el fín de hacer estudios comparativos y/o prospectivos.

2) Disminuir el tiempo de alimentación de una base de datos partiendo de una fuente, donde dicha fuente tiene una cantidad potencial de miles de registros de información. Estos registros pueden estar en uno o más documentos, los cuales pueden procesarse en más de una sesión, en el capítulo 4.1, se trata más sobre el tema.

4

3) Alimentación de una base de datos en base a diversas fuentes de datos.

El fin de esta estrategia es reducir el tiempo de alimentación y extracción de datos, mas no reemplazar de manera completa la intervención humana en el proceso, ya que esta intervención humana es importante para interpretar y validar los datos obtenidos durante el aplicación de la estrategia.

1.1 Antecedentes

El lenguaje HTML es el medio más difundido para presentar información en el World Wide Web (el cual se referirá como red en el presente documento), pues permite la manipulación de elementos visuales que faciliten a un usuario localizar información que busque al usar un software de navegación en la red.

No obstante, la mayor parte de los estatutos del lenguaje manipulan la presentación visual de los datos y no necesariamente se encuentran relacionados con los datos en sí. Esto, sin considerar la cantidad de elementos nativos de otros lenguajes ajenos al HTML, pero que interactúan con el navegador, tales como los mensajes pop-up y los scripts de lenguajes como JavaScript o PHP.

La especificación del lenguaje HTML es una serie de instrucciones, los cuales serán referidos como tags, que indican al software navegador la forma de desplegar en pantalla lo que se encuentre delimitado por dichos tags. Estos tags están constituidos por una palabra clave de inicio y otra de final, no obstante, la sintaxis del lenguaje es muy relajada y un navegador puede interpretar el tag perfectamente, aún cuando no cumpla la regla sintáctica del HTML.

Una tecnología derivada del HTML, es el lenguaje XML [2]. Este lenguaje poseé una sintaxis más estricta que el HTML, ya que se enfoca hacia la creación de lenguajes que faciliten el intercambio de información entre aplicaciones y no a la presentación de los datos que transporta. Es decir, el lenguaje XML es un lenguaje estructurado orientado a datos, mientras que el HTML puede verse como un lenguaje semi-estructurado cuya información define la forma de desplegar datos

5

en un navegador de red. Un documento HTML puede también ser un documento bien formado.

A su vez, un derivado del lenguaje XML es el lenguaje XSL [3], este lenguaje es un estándar del W3C que describe estilos de formato y presentación para documentos XML. Entre estos estilos se pueden generar archivos HTML y XML.

La característica principal del XML es estructurar información y asociar un significado semántico, dado que está orientado a definir contenidos, mas no presentación [4], ya que todos sus tags deben estar cerrados y anidados entre sí. A un documento XML que cumple esta característica se le llama bien formado, pero esta restricción no se aplica de manera completa en el lenguaje HTML. El lenguaje XHTML [5] fue diseñado para cumplir este requerimiento, ya que se caracteriza por la definición de documentos HTML que cumplan los requisitos de un documento XML bien formado.

Por ello, partiendo del hecho de que existe una cantidad considerable de fuentes que tratan sobre un determinado tema en la red y que además, comparten el número de elementos de información sobre el mismo tema (o por lo menos, una parte), se piensa que es posible crear un proceso que de la manera más automática posible busque valores para poblar los elementos de la estructura de datos sobre el tema mencionado. Sin embargo, el hecho de que las estructuras de distintos documentos que hablen del mismo tema no necesariamente serán idénticas [6], se vislumbra como un área de oportunidad la creación de una estrategia general que pueda extraer información de un tema, de distintos documentos HTML.

1.2 Objetivo

La propuesta del trabajo es: una estrategia cuya aplicación, permita facilitar la obtención de datos pertenecientes a una estructura de elementos referentes a un tema, pero que se encuentre desplegada de distintas formas, en documentos HTML de la red.

Parte de la estrategia consiste en proveer un conjunto de reglas para

crear la estructura de los elementos referentes a un área de conocimiento determinada, localizar datos referentes a estos elementos

6

en páginas de red y proporcione elementos de salida manipulables por un usuario. Esta estrategía va dirigida, en particular, hacia administradores de tecnologías de información que pueden encontrar utilidad en la obtención de información de un área de conocimiento, por ejemplo:

● Sistemas donde se capturen valores de manera periódica de distintas fuentes durante un lapso de tiempo determinado.

● Alimentar bases de datos nuevas, capturando información determinada de distintas fuentes, como un catálogo de materias de una carrera universitaria en distintas instituciones.

● Convertir la información en documentos a bases de datos, poseedoras de estructuras de almacenamiento de información diferentes a las existentes en estos documentos.

Los objetivos particulares de la investigación son:

1) Proveer una estrategia cuya aplicación facilite una extracción de datos de distintas fuentes, enfatizando el uso en páginas Web, de forma repetitiva.

2) Aplicar la estrategia en casos prácticos para evaluar su uso.

3) Representar datos sobre un dominio de información de forma que, su contenido sea el mismo entre distintas fuentes de información que difieran en la forma de almacenar y/o desplegar estos datos.

Hay que aclarar que no es objetivo de la estrategia reemplazar a un usuario humano para la obtención de datos, dado que éste será necesario para validar y verificar los datos obtenidos en el proceso; sino minimizar su rol en el proceso.

1.3 Situación Problemática

Es común que los programas que permiten crear documentos para la red no cuiden que los tags de una página Web estén cerrados y/o anidados, aunque aquellos que manejen una interfaz WYSIWYG (Siglas en inglés de “Lo que se ve es lo que se toma”) generen páginas bien

7

formadas. En la actualidad existen muchas páginas cuya creación no ha seguido las reglas de un documento bien formado; lo cual aplica tanto a páginas estáticas como dinámicas, pues los lenguajes que permiten la generación de páginas HTML dinámicas, no impiden la generación de código HTML que no se encuentre bien formado. Al realizar una búsqueda sobre un documento que no se encuentre bien formado, se dificulta obtener el valor exacto asociado a un elemento de la estructura. Supongamos el siguiente ejemplo2:

<font size = "2" face = "Arial, Helvetica, sans-serif" > <table cellSpacing="0" cellPadding="0" width="100%" border="0" id="table26">

<tr><td bgColor="#e3eaf6"><table cellSpacing="0" cellPadding="5" width="100%"

border="0" id="table27"><tr>

<td bgcolor="#FFFFFF"><p align="center">Copyright</ font > </p></td>

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

</tr></table>

En este ejemplo, la causa de que el documento no esté bien formado es el tag <font>, que se abre después que el tag <table>, pero se cierra antes. Esto dificulta el valor exacto del tag <p>, ya que surgen dos posibles escenarios:

1) ¿Se considera el string “</font>” como parte del valor del tag <p>? Si es asi, ¿Hasta donde llega el valor del tag <font>?

2) ¿Se considera el string “Copyright” como valor del tag <font> o del tag <p>?

Si bien existen herramientas que facilitan la búsqueda de información en documentos XML, o permiten ubicarse en una parte determinada de los mismos, requieren que los documentos estén bien formados, para evitar situaciones ambiguas como la presentada en el ejemplo. Además hay que considerar que una página de HTML se enfoca hacia la presentación; así, aunque se generen elementos bien formados que nos

2 El ejemplo fue tomado de la página http://www.pdaperformance.com, algunos tags fueron modificados con fines de ilustrar de mejor manera el punto.

8

ayuden a buscar, un cambio en la estructura de la página original puede hacer que una futura extracción de datos sobre la misma página arroje resultados distintos a los esperados. El concepto de extracción de datos en el contexto de este trabajo será tratado a mayor profundidad en el capítulo 2.

No obstante, la presentación puede variar entre documentos, mas no así la información que estos contengan y los datos que componen dicha información. Éste será un factor común que relacionará a los documentos que traten sobre el mismo tema.

1.4 Hipótesis

La hipótesis es diseñar una estrategia general para obtener de forma semi-automatizada elementos que satisfagan los requisitos de una estructura XML. Esta estructura, definida partiendo de un dominio de datos, debe representar información contenida en múltiples fuentes de páginas de red, sin importar su estructura sintáctica o la presentación de los datos.

Un factor común que relaciona páginas de red que traten sobre un determinado dominio de datos, o tema, son los elementos pertenecientes a dicho dominio. La existencia perenne de este factor común, es el que permite vislumbrar la posibilidad de crear una estrategia para buscar información sobre un tema definido y delimitado.

Para explicar de manera más clara el punto anterior, se retomará el ejemplo del dominio de partidos de fútbol. Todo documento HTML que trate el tema, incorpora el concepto de un partido, así como el resultado del mismo. Toda persona que deseé obtener información sobre partidos de fútbol, al consultar fuentes de información que traten el tema, buscará la estructura que define un partido, para saber el resultado. La persona va a buscar determinados elementos, en este caso un equipo local, un equipo visitante y los respectivos marcadores, para interpretar el resultado de un partido.

La interpretación de los elementos es importante. En la línea del partido del fútbol, es factible pensar que con el simple hecho de localizar un número ya se encuentra la cantidad de goles que anotó un equipo, sin embargo, existen equipos que llevan números en sus nombres

9

(ejemplo: Schalke 04 de la liga de fútbol alemana, o Bundesliga) por lo que es necesario interpretar la información existente antes de realizar algún proceso.

1.5 Alcance

La presente investigación se enfocará principalmente a definir los fundamentos de la estrategia que permita la extracción de datos de fuentes de información semi-estructuradas, tal como una página de red (también llamadas Web). Así como su factibilidad, demostrable a través de dos casos prácticos:

1) La alimentación de una base de datos partiendo de un documento de HTML estático. Posteriormente, aplicar la estrategia de extracción en otro documento, para comparar los datos extraídos en ambos casos.

2) La alimentación de una base de datos partiendo de un documento HTML dinámico cuyo contenido cambia con el tiempo.

Así como la usabilidad de la estrategia en ambos casos, la cual se propone medir de acuerdo al caso:

1) Tiempo invertido en el uso de la estrategia contra el tiempo invertido para la extracción de datos sin la misma.

2) Constancia en los datos al extraerse de la misma fuente de datos, pero en diferentes instantes de tiempo.

En los capítulos posteriores se tocará este punto a mayor detalle.

1.6 Justificación

Muchos sistemas requieren alimentación al principio de su ciclo de vida, así como de manera constante, a lo largo del tiempo de uso del sistema. La red puede ser una fuente de información para alimentar dichos sistemas, pues todo sistema se encuentra enfocado en una determinada área de información. Dado que las estructuras

10

representantes del dominio de datos que abarque dicha área de información será la misma sin importar la forma y/o cantidad de documentos, puede existir una forma de minimizar el tiempo de alimentar dichos sistemas, automatizando la mayor parte de dicho proceso. Se parte de la suposición de que el tiempo invertido en revisar información es menor, que en capturar los datos que constituyen la misma.

Como ya se ha mencionado, la necesidad de interpretar los datos es la que permite la existencia de reglas para definir elementos del área de conocimiento, ya que estas reglas definen el orden de presentación de datos, o los elementos que constituyen a cada dato. Estas reglas existirán en todo documento contenedor de información del área de conocimiento. Por ejemplo, para una estructura que represente el resultado de un partido de fútbol, se pueden apreciar las siguientes reglas:

1) Deben existir dos equipos participando en el partido y los respectivos marcadores de cada equipo.

2) El equipo, que juega la mayoría de sus partidos en el estadio donde se realiza el mismo, se considera local.

3) El otro equipo se considera visitante.

4) El marcador de cada equipo es una cantidad numérica mayor a cero.

5) El orden por defecto para presentar estos datos es: Equipo local, marcador local, marcador visitante, equipo visitante.

1.7 Resultados Esperados

La investigación se aplicó en dos casos prácticos:

1) Extracción masiva de una fuente de información de miles de elementos. La finalidad de este caso es analizar el comportamiento de la estrategia para encontrar registros que cumplieran la estructura de búsqueda definida, así como el manejo de situaciones donde no se encuentran todos los

11

elementos de dicha búsqueda. El objetivo es verificar si esta estrategia puede ayudar a la alimentación masiva de una base de datos.

2) Seguimiento en el tiempo de una misma fuente de información. Con el fin de corroborar si la extracción de información de una misma fuente de datos en el tiempo, permanece constante.

El detalle de los resultados de los casos prácticos se explicarán con mayor detalle en el capítulo 4.

El documento está organizado de la siguiente manera:

● El capítulo 1 consiste en la introducción y definición de los objetivos y alcance del documento.

● El capítulo 2 consiste en los fundamentos teóricos y tecnológicas de esta investigación. En este capítulo se abordan otros trabajos y se explican, de manera breve, que diferencias tienen contra el actual documento. También se describen los distintos conceptos manejados a lo largo del documento.

● El capítulo 3 describe la estrategia general de extracción, así como los fundamentos de la extracción de datos.

● El capítulo 4 describe los casos prácticos sobre los que se aplicó la estrategia, haciendo relación con los conceptos y pasos definidos en el capítulo 3.

● El capítulo 5 contiene las aportaciones del trabajo, así como trabajos futuros, y aplicaciones propuestas.

● El capítulo 6 contiene las conclusiones generales del trabajo.

● Al final del documento se incluye un apéndice con información detallada de las estructuras usadas en los casos prácticos.

12

Capítulo 2. Fundamentos técnicos y tecnológicos

En este capítulo se discutirá el marco teórico en que se fundamenta la investigación, así como la mención de trabajos alternos y conceptos que se manejarán a lo largo del documento.

2.1 Marco teórico

A lo largo del documento, se mencionará el lenguaje XML. Este lenguaje permite representar documentos bien formados, los cuales definimos como aquellos que describen estructuras de datos usando etiquetas, también llamadas tags, proveyendo una semántica a sus contenidos. No obstante la rigidez que este tipo de documentos puede poseer, sigue siendo menor a la que presentan otras herramientas que almacenan estructuras de datos como puede ser una forma para una base de datos [7]. Los tags llegan a tener cantidades de información sumamente específica.

Otro tipo de documentos son los semi-estructurados, cuyas diferencias principales con respecto a los documentos bien formados son:

1) Un documento semi-estructurado no necesariamente exige que cuando se abre un elemento se cierre antes de abrir el siguiente. Esta situación se mencionó en la sección 1.3.

2) Los tags delimitan gran cantidad de información relevante a un determinado dominio de interés. Como en los documentos de lenguaje HTML, cuyos tags contienen información concerniente al desplegado visual de información, principalmente en navegadores de Web.

Un documento HTML es un ejemplo de documento semi-estructurado, pues posee los tags que regulan la forma de presentación visual de los datos, sin embargo, los tags de tipo <p> (paragraph) contienen información que puede separarse de manera granular. Hay que notar

13

que esta información tiene un significado semántico para un lector humano, pero no tendrá una relación sintáctica directa con una estructura de datos definida.

El hecho de que un documento bien formado tenga su información de manera granular lleva a pensar que es fácil realizar una búsqueda de información, pero no necesariamente es así, debido a que el lenguaje permite el almacenamiento de datos, pero no provee operaciones para la consulta de los mismos. Se han desarrollado herramientas cuyo objetivo es facilitar esa funcionalidad al usuario, tales como XQL o XQuery.

2.2 Trabajos sobre extracción de datos

Existen proyectos enfocados a extraer información de documentos bien formados (o semi-estructurados), de los cuales varios se exponen a continuación.

2.2.1 Búsqueda de cambios en datos semi-estructurados

Definido en [6]. El trabajo de Chawathe, Abiteboul y Widom se enfoca en representar cambios en páginas HTML, a las que en el documento, se consideran como documentos semi-estructurados. Ellos proponen un modelo para representar un registro de los cambios en datos semi-estructurados, incluyendo un lenguaje para la realización de búsqueda de datos considerando ese registro de cambios.

El trabajo trata de resolver el problema de buscar información en documentos semi-estructurados. Es uno de los primeros trabajos que proponen una solución al problema de buscar datos en documentos semi-estructurados debido a “la irregularidad y carencia de un esquema” en los mismos [6]. La propuesta radica en comparar dos páginas de Web, que son documentos semi-estructurados para propósitos del trabajo, con el fin de localizar los cambios y llevar un registro de dichos cambios en los mismos datos.

La aproximación es interesante y sirve para ilustrar los primeros pasos en la búsqueda de extracción de información de documentos

14

semi-estructurados. El punto más importante es que considera la estructura de datos existentes para buscar las diferencias. El modelo propuesto en el trabajo es capaz de detectar diferencias de contenido, debido a la existencia de palabras clave que sirven como punto de referencia para detectar cambios en la información de la página, mas no cambios en la presentación de la misma. Son de destacar los siguientes puntos:

1) La distinción realizada entre la información contenida en los documentos, sobre la presentación de los mismos.

2) La necesidad de realizar transformaciones en los documentos semi-estructurados dadas las limitantes de un documento de este tipo para la realización de búsquedas de datos.

2.2.2 Transformación a documento bien formado

Definido en [8]. Este trabajo propone la transformación de un documento semi-estructurado a un documento bien formado, expandiendo el concepto de transformación del documento semi-estructurado, mencionado en la sección anterior.

El documento presenta las siguientes justificaciones para la transformación de los documentos semi-estructurados de lenguaje HTML, hacia documentos bien formados siguiendo las reglas del lenguaje XML:

1) Eliminación de ambigüedades y errores generados durante la creación del documento semi-estructurado HTML.

2) El hecho de que el documento bien formado, cumpla con los requisitos de un documento bien formado de XML, permite la utilización de técnicas y herramientas que puedan trabajar sobre dicho tipo de documentos. Un ejemplo de los trabajos que se pueden realizar sobre este tipo de documentos es alimentar una base de datos.

Es posible ver este trabajo como un antecedente a la definición del lenguaje XHTML [5], ya que este lenguaje define la creación de documentos HTML, pero bien formados.

15

En el trabajo [9] se propone otra razón por la cual es necesario realizar la transformación de un documento semi-estructurado HTML hacia un documento bien formado. Un documento semi-estructurado posee una importante característica que es el acomodo de su información en una estructura jerárquica. Esta característica es compartida por un documento bien formado, con el beneficio añadido de que en los documentos de este tipo la estructura se encuentra definida de manera más rigurosa. Esta rigidez en la definición de la estructura, facilita la transición de los datos contenidos en la estructura hacia un modelo de datos relacional, donde la rigidez de las tablas que almacenan la información facilita relacionarlo con los elementos del documento bien formado.

2.2.3 Extracción de datos de páginas Web

Definido en [1]. El trabajo de Jussi Myllymaki, es base para el modelo de extracción de información ANDES3. Aborda conceptos y problemas al extraer información de documentos semi-estructurados HTML. Si bien, el lenguaje HTML es el mayor conductor de información a través del World Wide Web y provee una forma conveniente de desplegar información a lectores humanos; sin embargo, “es una estructura retadora para automáticamente extraer información relevante a servicios orientados a datos o a aplicaciones” [1], debido a los siguientes factores:

1) La mayor parte describe formato irrelevante a los datos desplegados en la página, mas no para la comprensión visual de la información desplegada.

2) Por la displicencia de los navegadores de páginas del World Wide Web a interpretar documentos HTML que no se encuentren bien formados.

3) La existencia de código que despliega anuncios publicitarios o contenidos que varían de forma dinámica por cada conexión al servidor que contiene las páginas. Generalmente, este código es irrelevante con respecto a la información desplegada en la página final que se muestra al usuario.

3 La relación del modelo ANDES en el marco de esta tesis, se explica con mayor detalle en la sección 3.1.

16

La propuesta de Myllymaki [1] propone que el proceso clave para la extracción de datos, contenidos en documentos HTML, es convertir dichos documentos a documentos bien formados y estructurados de tipo XHTML, para aprovechar las herramientas existentes para trabajar con documentos de este tipo. Esto ya es un paso adelante del trabajo propuesto en [8], ya que el lenguaje XHTML está plenamente definido y cumple con los requerimientos planteados en dicho trabajo.

Otro concepto importante que se define en este trabajo es el punto de referencia para buscar un determinado dato. La existencia de un punto de referencia permite evitar buscar en todo un documento por un determinado dato.

Las propuestas de este trabajo, son analizadas a mayor detalle en el capítulo 3, donde se propone la estrategia general para la extracción de datos.

2.2.4 Estructura de búsqueda por dominio

Definido en [10]. Este proyecto propone un modelo de extracción basados en un esquema de datos, donde no se necesita interacción humana, pero se basa en una estructura de búsqueda4 perteneciente a un dominio de datos.

El trabajo de Arasu y García propone que muchos servidores de Web tienen grandes colecciones de páginas que tienen una estructura visible, donde dicha estructura describe la forma en como se guarda esa información, como en una base de datos. Estas páginas no suelen ser documentos estáticos, sino que se generan de manera dinámica en un servidor obteniendo información de la base de datos; mas no hay que olvidar que el resultado final de dicha generación es un documento HTML estático interpretado por un navegador.

Dentro de este documento estático, si bien es posible percibir la estructura de información mencionada por los autores, distinguirla sin otorgarles un significado es difícil, principalmente por dos razones:

4 Este concepto se desarrolla a mayor detalle en el capítulo 3

17

1) Existen niveles de anidamiento de información arbitrarios, que no necesariamente se repetirán en todas las páginas. Un ejemplo se aprecia en la clasificación taxonómica de plantas, ya que algunos géneros tienen sub-géneros, a su vez, dentro de los sub-géneros, vienen las especies; pero otros géneros no poseen ese nivel intermedio y contienen directamente a las especies. Eso sin contar, que algunos sub-géneros podrían contener sub-sub-géneros, o que algunas especies cuentan con sub-especies y/o razas.

2) La distinción de la presentación y los datos en sí. De manera sintáctica, no existe virtualmente nada que ayude a distinguir el texto que es la presentación y el texto que contiene los datos. Un ejemplo es la omisión de los tags de encabezados <th> dentro de una tabla, ya que el uso de esas etiquetas ayudan a distinguir los encabezados de una tabla, pero no siempre se usan y no son requisito fundamental para el desplegado de un tabla en un documento HTML.

Estos problemas se atacan, proponiendo un algoritmo que, partiendo de una estructura de datos a buscar definida por el aplicador del algoritmo, clasificará páginas de web de acuerdo a la inclusión de datos de dicha estructura, encontrará posibles equivalencias con la estructura y finalmente extrae los valores que se consideran correctos.

La meta final de la investigación de Arasu y García es atacar el problema de extraer datos con aplicaciones de integración de sistemas, la meta compartida en esta tesis es el aspecto referente hacia la extracción de datos.

2.2.5 Estructuras similares

Definido en [11]. En este caso se propone interpretar los documentos a buscar como estructuras similares, además introduce el concepto de frecuencias en los documentos de búsqueda. La idea de estructura similar se traduce en que todo documento HTML puede interpretarse como un documento bien formado, sin embargo, difiere en que la similitud radica en distinguir los elementos a buscar, como listas o celdas de tablas.

18

El trabajo de Flesca, Manco, et al, aborda un aspecto no contemplado en el trabajo anterior [10]: los niveles de anidamiento. Por medio de la serialización de documentos XML en representaciones numéricas, para posteriormente, buscar la frecuencia de dichas representaciones numéricas en otros documentos codificados de dicha forma, apoyándose en herramientas matemáticas como transformaciones de Fourier para lograr dicho propósito. Hay que hacer notar que no es el único trabajo que se apoya en herramientas matemáticas para la extracción de datos, otro ejemplo es la propuesta de PXML [12].

La idea central es: partir de un documento XML que define una estructura de datos a buscar y representarlo de una determinada forma numérica; si se localiza otro documento, que al ser representado también numéricamente, tiene similitudes con la estructura de datos a buscar, es posible que satisfaga los datos que dicha estructura define.

El concepto de estructura similar es interesante, pues páginas que contengan información sobre el mismo tema tendrán elementos en común, mas su orden de presentación no será idéntico, de ahí que se use la palabra similar, denotando que son parecidos, mas no iguales.

2.2.6 Estrategia “Dividir y Vencer”

Definido en [13] y [14]. Esta propuesta se basa en una estrategia de dividir y vencer, para encontrar árboles de datos. Parte de esta estrategia fue adaptada para los ciclos de búsqueda, donde se busca que los datos ya estén acomodados en una estructura de datos de un dominio; ya que los datos contenidos en un dominio, generalmente poseen un orden determinado.

La premisa parte de [14], donde se propone la búsqueda de contenido similar, por medio de reglas de asociación en partes de un documento bien formado, mas no en la totalidad de éste. La idea se complementa en [13], donde el objetivo es buscar en la menor cantidad de elementos diferentes dentro de un documento XHTML, obtenido al transformar el documento HTML en un documento bien formado, ya que los datos quedan contenidos en un número restringido de elementos. Esto se explica a mayor profundidad en la sección 3.5 de este documento.

19

Los autores Feng, Hsu y Lee [13] proponen que al buscar una determinada estructura de búsqueda, denominado árbol en su trabajo, tiene un determinado orden, es posible distinguir elementos de dicho árbol en otras estructuras ordenadas a un determinado orden, lo cual ayudaría a buscar solo determinadas ocurrencias de un conjunto de los elementos en lugar de buscar toda la estructura. El concepto de “árbol” puede considerarse una aplicación del concepto “Punto de Referencia” mencionado en la sección 2.2.3.

Retomando los ejemplos concernientes a partidos de fútbol En determinados torneos, como la Copa del Mundo de Fútbol Soccer, una definida cantidad de partidos tienen relevancia dentro de un grupo que abarca determinados equipos, ya que cada equipo de ese grupo solo realizará partidos contra los de su mismo grupo, al menos durante una definida fase del torneo.

En este caso, supongamos una estructura de la siguiente forma:

<ronda><grupo>

<partido/>....

</grupo><grupo>

<partido/>....

</grupo></ronda>

Si el tipo de datos que estamos buscando son los resultados de partidos, es lógico asumir que una vez encontrado un grupo, donde después de ese grupo hubo partidos, si se vuelve a encontrar un grupo, en la misma ronda, también tendrá partidos. A esta situación es la que se describe como estructura similar.

Otro trabajo, que puede considerarse relacionado en este tópico, es [15], donde se maneja el concepto de “Búsquedas de objetos cercanos”. En este concepto se propone que dada la proximidad de un elemento en una estructura de búsqueda; si dicho elemento se encuentra en el documento semi-estructurado que funge como fuente de datos, existe una fuerte posibilidad de encontrar elementos que estén cercanos a éste, o se consideren “hijos” del mismo.

20

Retomando el ejemplo abordado en esta sección, vemos que el elemento “grupo” se considera hijo del elemento “ronda”. Al realizar una búsqueda de información en un documento semi-estructurado que contenga la palabra “ronda” es posible inferir que valores que satisfacen el elemento “grupo”, o el elemento “partido”, se encontrarán en dicho documento, encontrados posteriormente a la ocurrencia del elemento “ronda”.

De esta forma, al encontrar una ocurrencia de un determinado elemento en la estructura de búsqueda y dicho elemento tiene elementos “hijos”, es fácil asumir que por cada ocurrencia de este elemento, tendrá también valores que satisfacen los valores de uno o más de sus “hijos”.

2.2.7 Extracción de datos usando XML

Mostrado en [16]. Es un trabajo orientado a la generación de un marco de trabajo para la extracción de datos de documentos XML. La interpretación que se da en dicho trabajo al concepto de extracción de datos se traduce en el hallazgo de patrones, aplicados a una gran cantidad de información aparentemente sin relación entre sí y generar reglas de asociación que permita establecer relaciones, si es que las hay.

El concepto planteado es interesante, debido a que “ha habido muy poco trabajo en el dominio de minado por reglas de asociación de documentos XML” [16]. Este trabajo se considera, porque el propósito fundamental es el mismo: extracción de datos de documentos bien formados.

Se toman los siguientes conceptos de dicho trabajo:

1) Las reglas de asociación que pudieron generarse durante la primera ejecución del marco de trabajo propuesto, facilitan la extracción de datos en futuros documentos. Dicho concepto se ve reflejado en el concepto de estructura de búsqueda de esta estrategia de extracción. Agregando además la posibilidad de que dicha estructura puede modificarse para adaptarse a otra fuente, aunque no de manera automática como propone el trabajo [16].

21

2) Un documento XML se debe organizar de una manera adecuada para poder realizar una búsqueda más eficiente. Es muy importante resaltar que este apartado se refiere al documento XML fuente de información. Este concepto se ve reflejado en la transformación de la página de HTML en un documento XML bien formado XHTML, eliminando los elementos referentes a la presentación de la información, ya que la información en un documento XHTML queda en elementos muy determinados. Se detalla más este concepto en la sección 3.5 de este trabajo.

2.2.8 Modelo de búsqueda de información ANDES

Mostrado en [2]. Este modelo puede ser considerado una aplicación del trabajo mostrado en [16], ya que realiza aplicaciones repetitivas de documentos XML y XSL sobre documentos HTML para extraer información, para depositar la información obtenida en una estructura de datos XML definida previamente.

Este modelo se considera como punto de partida de la estrategia mencionada en esta tesis, considerando tanto el uso de lenguaje XML para la creación de estructuras de búsqueda de información, como del repositorio de información. Se discute a mayor detalle en la sección 3.1, dada su importancia como base de este trabajo.

2.2.9 Really Simple Syndication

La popularidad del formato de archivos Really Simple Syndication [17] (RSS por sus siglas en inglés), ha aumentado debido a su uso en la difusión de cambios o adición de contenidos en sitios de Internet. Este formato permite a un usuario, por medio de un software que lea este tipo de archivos, percatarse de cambios en los contenidos de un sitio de Internet, lo cual puede interpretarse como el seguimiento en el tiempo de un sitio.

Un ejemplo del uso de este tipo de archivos, es en los portales de periódicos, donde por medio de estos archivos se le informa a un usuario sobre los artículos más recientes en dicho portal. Esta tecnología arroja un concepto usado en este trabajo: el seguimiento de información de una fuente a través del tiempo. El formato RSS permite al usuario

22

mostrar las diferencias que han ocurrido en una fuente con el paso del tiempo, si bien, no facilita realizar la captura de dicha información y almacenarla en una base para futuros cotejos, lo cual es la raíz del caso práctico Seguimiento en el tiempo de una fuente de información el cual se ve en la sección 4.2.

2.3 Conceptos

El primer concepto a explicar, ya mencionado con anterioridad en el documento, es el de dominio de datos, que consiste en una serie de reglas y elementos relacionados con un área del conocimiento determinada.

Dada la granularidad que caracteriza los documentos bien formados, es posible representar las reglas que definen un dominio de interés en lugar de la información correspondiente a dicho dominio, pues esta descripción tiene que ser lo más concreta posible, dejando la información definida en documentos semi-estructurados, que no necesitan ser tan rígidos.

Retomando el ejemplo de un partido deportivo como área de interés mencionado previamente, una representación del dominio es la siguiente:

<encuentro> <participante> <nombre>string</nombre> <local>Boolean</local> <marcador>numero</marcador> </participante></encuentro>

El ejemplo es un documento bien formado, pues cada pieza de información está contenida en una unidad pequeña. En este caso en particular cada tag que contendrá datos, tiene el tipo de dato que contendrá y donde el nombre del tag, es el nombre del dato a almacenar. A la estructura cuya descripción se encuentra en el documento bien formado de este tipo, se le llama estructura de búsqueda.

23

Ahora, hay que buscar los datos que cumplirán los elementos especificados en la estructura de búsqueda. Estos datos se encuentran en documentos de texto libre, o en el mejor de los casos en documentos semi-estructurados. Al proceso de búsqueda y extracción de estos datos, en distintos documentos, se le llama extracción de datos.

La forma en que pueden estar estos datos varía considerablemente, consideremos una nota de periódico:

En un trepidante partido, los Rayados del Monterrey fueron capaces de imponerse a su acérrimo rival, los Tigres por marcador de 3 goles a 1.

Los participantes son los strings “Rayados de Monterrey” y “Tigres” y los marcadores son “3” y “1” respectivamente. El valor del campo local no tiene una correspondencia directa con alguna palabra en el párrafo anterior, pero el significado semántico de la redacción de la nota para un lector humano es que Rayados es el participante local.

Ahora consideremos un fragmento de una página de red HTML que contiene los resultados de una jornada.

Rayados 3 1 Tigres

Donde parte del código HTML para obtener el desplegado anterior, en el documento semi-estructurado, es el siguiente:

<tr> <td>Rayados</td> <td>3</td> <td>1</td> <td>Tigres</td></tr>

Es exactamente la misma información que en la nota periodística, pero se encuentra representada de manera diferente. Dado que es un fragmento de una tabla que contiene más resultados, es posible inferir que el primer participante es el que cumple el requerimiento de local.

En este punto se ha ilustrado que la información puede encontrarse almacenada en más de una forma, aun cuando sea la misma información. Al documento que contiene la información a ser extraída se le llama fuente de datos.

24

La fuente de datos si bien posee la información que llene la estructura de búsqueda, no necesariamente contiene dicha información en el orden especificado en dicha estructura de búsqueda. Por eso, cualquier fuente de datos pasa por un proceso de transformación [7], que consiste en la aplicación de un conjunto de reglas, donde cada tipo de regla cumple un propósito diferente:

• Reglas de selección: Buscan los tags definidos en la estructura de búsqueda. El propósito de estas reglas es detectar en la fuente de datos donde están localizados los nombres de los datos.

• Reglas de extracción: Buscan la información en estructuras cercanas a donde fueron localizados los nombres de los datos.

• Reglas de estructura: Buscan cumplir las especificaciones de la información que contendrá el dato y cuyas características se encuentran en el documento de estructura de búsqueda.

• Reglas de procesamiento: Realizan transformaciones necesarias sobre los datos para cumplir requerimientos en el documento de estructura de búsqueda. Este tipo de regla aplica cuando existe un requerimiento determinado para el dato y se encuentra un valor que no corresponde con el requerimiento. Esta regla es propuesta en este trabajo y no se encuentra en las sugeridas por [7].

2.4 Integración de datos

De acuerdo al dominio de datos del cual se desea obtener información, es posible definir en una estructura los datos que se desean extraer de las páginas semi-estructuradas HTML. Sin embargo, la estructura pudiera ser percibida de manera semántica por un lector humano, es más complejo para una aplicación automatizada de datos [1]. Dicha complicación puede obedecer a diversos factores [4]:

● Modelos de datos diferentes: Las fuentes de información, en este caso, los documentos HTML mostrados en un navegador5,

5 Si bien estos documentos pueden crearse, seleccionando información de una base de datos existente en un servidor, el usuario del navegador de World Wide Web, no tiene acceso directo a la estructura de dicha

25

pueden desplegar de manera distinta la misma información.

● Esquemas de datos diferentes: Entre diferentes modelos de datos, puede existir alguno de los siguientes escenarios:

Una palabra puede referirse a elementos diferentes en distintos modelos. Un elemento puede referirse de distinta forma en modelos diferentes.

● Instancias de datos diferentes: El hecho de que dos fuentes de información diferentes, se refieran al mismo elemento, de forma contradictoria entre sí. Por ejemplo: una persona con dos fechas de nacimiento diferentes.

Sin embargo, existe un factor común en las distintas fuentes de datos sobre un dominio de datos y es el dominio de datos en sí. Los elementos que pertenecen a dicho dominio, deben aparecer en las distintas fuentes de datos que tengan información sobre dicho tema. Por lo tanto, es necesaria la existencia de un factor que permita heterogeneizar la información que se desea obtener y que satisfaga un dominio de datos determinado. Se considera que una estructura que cumpla con los requisitos del lenguaje XML, es decir, un documento bien formado, cumple con este propósito. La utilización de estructuras definidas en este lenguaje se explica a mayor detalle en el capítulo 3.

Además, hay que considerar un cierto principio de incertidumbre que existe en todo dominio de datos [12]. Este principio se puede resumir en las siguientes preguntas:

● ¿Existen en el documento todos los elementos que conforman la estructura de datos?

● ¿Existe la certeza de que los valores de las fuentes son válidos dentro del dominio de datos?

Dado que no es sencillo responder a estas preguntas antes de realizar la extracción de datos, es necesario crear mecanismos que permitan lidiar con estas preguntas.

base de datos. Por esta razón se consideran como fuente de información los documentos generados.

26

2.5 Conclusiones

La variedad existente de mostrar información, puede dificultar la tarea de un proceso de extracción automatizada de la misma, cuando se trata de extraer dicha información de documentos con estructuras diferentes, o de un mismo documento, cuyo formato para presentar la información ha cambiado en el transcurrir del tiempo.

Si bien existen varios trabajos sobre la extracción de datos de documentos bien formados o semi-estructurados, como los mencionados en este capitulo, se considera que éstos adolecen de flexibilidad para extraer información de distintas fuentes, o bien pudieren tener dificultad para lidiar con cambios en una misma fuente. Por cada trabajo se exponen las siguientes diferencias:

Estructura de búsqueda por dominio [10]: No considera el uso de una misma palabra en distintos dominios de información; así como el uso de distintas palabras para referenciar el mismo elemento de información.

Estructuras similares [11]: Si bien la idea de estructuras similares para buscar tiene utilidad, el lenguaje HTML permite desplegar de distintas formas una misma información. En esta situación se considera que una estructura de búsqueda, a como está planteada en el trabajo, batalla en páginas diferentes que muestren la misma información, como tablas anidadas dentro de tablas.

De igual forma, si una página cambia su estructura, o los nombres de los elementos que crearon la representación numérica también cambian, la utilidad de dicha representación disminuye.

Estrategia “Dividir y Vencer” [13]: La idea base de este trabajo, se ve reflejada en la estrategia de extracción propuesta en esta tesis. Sin embargo, de la manera definida del trabajo [13] se considera el siguiente punto débil: se asume que un elemento va a tener exclusivamente un valor concerniente a un elemento de la estructura de búsqueda que se trata de llenar, no se tiene contemplado que sucede cuando en un mismo elemento puede haber valores que satisfagan a más de un elemento de la estructura de búsqueda.

27

Extracción de datos usando XML [16]: Proporciona la idea y justificación del uso de una estructura de búsqueda en lenguaje XML. Sin embargo, su orientación dirigida hacia la búsqueda de patrones relacionando información, difiere del propósito central de la actual tesis, orientado hacia el uso de una estructura de búsqueda previamente definida.

En el capítulo 3 se expone a mayor detalle las aportaciones de esta tesis que complementan los trabajos mencionados en este capítulo.

Se propone el uso de las estrategias de extracción para alguno de los siguientes escenarios:

1) Llenar una base de datos a partir de distintas fuentes, como un catálogo de carreras, de un área de conocimiento determinada, de distintas universidades.

2) Estandarizar distintas estructuras de información en una sola.

3) Copiado masivo de información hacia una base de datos.

4) Seguimiento en el tiempo de una misma fuente de información.

Es de notar, que la idea de almacenar información en una base de datos relacional, donde los datos se guardan en tablas definidas por una determinada estructura, presentan una diferencia primordial con los elementos semi-estructurados de donde se desea extraer la información; ya que éstos tienen como característica importante, una estructura jerárquica donde se almacena la información [9]. Un documento bien formado facilita la transformación de datos, localizados en una estructura jerárquica hacia una estructura relacional.

En el siguiente capítulo, se explicará la extracción de datos que se hará a los distintos documentos de web, aplicando los conceptos mencionados en este capítulo.

28

Capítulo 3. Fundamentos de la Extracción de Datos

En este capítulo se explicará a mayor profundidad la extracción de datos que se realizará sobre documentos semi-estructurados para obtener información.

Primero se abordará la explicación de la metodología ANDES, que sirvió como punto de partida para este trabajo, posteriormente se desarrollarán conceptos que se manejarán a lo largo del documento y dentro de cada concepto, las actividades a realizar para la obtención de datos.

De igual forma, en las secciones donde se considera conveniente, se mencionan los puntos en desacuerdo con los trabajos mencionados en el capítulo anterior, o en su defecto, los puntos que se han incorporado de dichos trabajos en la realización de las estrategias de extracción de información sugeridas en este documento.

3.1 Extracción de datos

La extracción de datos es un proceso que toma elementos de procesos ya definidos previamente de la extracción de datos en páginas Web [1] y del modelo de búsqueda de información ANDES [18]. El resultado final es mostrar el resultado de la extracción en un documento XML bien formado [2]. Hay que destacar que este documento va a contener los datos extraídos

ANDES es un conjunto de siglas que quiere decir “A Nifty Data Extraction System” en inglés. Es un método propuesto por Jussi Myllymaki de IBM, que define una plataforma sobre la cual “construir un proceso de extracción de datos en red con calidad de producción” [18]. La figura 3.1 muestra la metodología del modelo ANDES original. Esta metodología propone definir un conjunto de extractores, que son estructuras definidas en XML, aplicadas de manera iterativa sobre un documento HTML, de forma que al aplicar el último de los extractores se genera una estructura de salida deseada.

29

Figura 3.1. Flujo del proceso.

Sin embargo, se ven algunos inconvenientes que este trabajo busca responder:

1) Un primer paso es que el extractor se aplica sobre un documento XHTML. Si bien es posible extraer información, se considera que el documento debe estar bien formado de acuerdo a los estándares XML, como es propuesto en [8]. Además la proliferación de códigos para el formato del documento de manera dinámica como JavaScript y CSS, puede confundir al extractor de información y no se considera relevante para la información contenida en el documento.

2) La dificultad de localizar datos dentro de celdas en tablas, no especificadas en el caso de ANDES, pero que se propone en este trabajo para realizar una extracción más efectiva.

3) Desde un punto de vista de mantenimiento de estructuras de

30

búsqueda, puede ser complicado manejar varios niveles de extracción y acomodo. Por lo que se considera más práctico manejar una estructura final única.

3.2 Propuesta de la estrategia

La figura 3.2, representa la estrategia propuesta en este trabajo, según la cual, el punto de partida es un documento escrito en lenguaje HTML, que puede provenir ya sea del World Wide Web, o como alternativa, se puede convertir un documento de otro formato, a lenguaje HTML. Para garantizar que sea un documento bien formado, se procede a transformarlo en un documento XHTML, un documento de información HTML que cumple con las reglas sintácticas del XML, convirtiéndolo en un documento estructurado bien formado.

Figura 3.2. Proposición de la estrategia.

31

El siguiente paso, es que este documento sufrirá una segunda transformación que consiste en:

● Enumerar celdas en tablas para poder distinguir filas y columnas, con el fin de facilitar la ubicación de celdas donde se localice información

● Eliminar elementos HTML que no contienen información, tales como los tags que definen lenguajes Javascript.

● Eliminar tags HTML que definen formato, tales como <i> y <b>.

Estas transformaciones se realizan por medio de un archivo XSL, el cual genera un documento XHTML con los tags que deberían contener la información a extraer del documento. En base a dicho documento generado, se crea un segundo XSL que transformará el documento XHTML en la estructura XML que contendrá los elementos a buscar. Este documento XSL es el que contiene las reglas de selección y extracción de información.

La razón por la cual se opta por dejar el resultado final en un documento XML es para aprovechar la características de los documentos de este lenguaje: poder usarlos en distintas aplicaciones. No obstante, se puede hacer la siguiente observación: ¿porqué realizar la transformación de un documento HTML a un XML, para luego volverlo a transformar a un documento XML? La respuesta reside en que hay documentos HTML generados de manera dinámica por el servidor de Web, obteniendo la información a mostrar en la página de una base de datos; pero la forma en que el usuario recibe esta información es por medio de las páginas, para no tener que otorgarle acceso directo a la base de datos. Aquí se propone extraer la información de los documentos que un usuario tiene acceso, en este caso, las páginas HTML generadas.

3.3 Definición de estructura de Búsqueda

El primer paso es definir una estructura de datos XML que contiene los elementos a buscar en las páginas Web. Cada elemento debe tener un nombre, puede tener un valor por defecto y uno o varios sinónimos. La estructura propuesta tiene la siguiente forma:

32

<dato @multiple=”si” @requerido=”si” @delimitador=”|”>nombre1<default>valor default 1</default><dominio>dominio de datos</dominio><tablas>fila</tablas> <sinonimo>sinonimo1</sinonimo> <sinonimo>sinonimo2</sinonimo></dato><dato @multiple=”no”>nombre2 ….</dato>

Donde cada elemento del documento está definido de la siguiente forma:

• Dato: Su valor es la palabra que será usada como punto de referencia en la búsqueda. Además puede contener otros elementos de este tipo para representar datos jerarquizados. Este elemento tiene a su vez tres atributos:

o Multiple: Puede haber más de una instancia en la base de datos que contenga un valor válido para este dato. Esta situación puede darse en estructuras de datos jerarquizadas. El valor por default para este atributo es si.

o Requerido: En caso de no hallar un punto de referencia relacionado con el dato o con sus sinónimos, indica que debe proceder con el dominio o el default.

o Delimitador: En caso de hallar el punto de referencia en el tag de XHTML, indica si toma los caracteres a partir del punto de referencia hasta el carácter indicado en el atributo. En caso de no proporcionase, considera el valor como el string que inicia a partir del fín del punto de referencia hasta el fin del tag.

• Default: Un valor a colocar en la estructura de salida en caso de que no se halle ni un elemento, ni un sinónimo, ni un elemento del dominio de datos solo si el valor del atributo “requerido” es “si”. Es posible indicarlo si no existe valor del atributo “requerido”, pero el proceso lo ignorará. La inclusión de este elemento es una propuesta para resolver una de las preguntas planteadas en [12]: ¿Existen en el documento todos los elementos que conforman la estructura de datos?

• Dominio: Es un dominio de datos que muestra que tipo de cadena

33

de caracteres debe buscar en la página en caso de no encontrar un punto de referencia que satisfaga el elemento o sus sinónimos. Se recomienda el uso de expresiones regulares para facilitar la búsqueda de datos.

• Tablas: Indica como debe buscar los datos en tablas. Aplica en aquellos casos donde el valor hallado en una tabla pudiera pertenecer a un determinado dato. Solo puede contener dos valores:

o Fila. El valor por default. En esta situación, el valor del dato “padre” se encuentra en la primera columna y el valor de este dato hay que buscarlo en columnas a la derecha.

o Columna. En esta situación, el valor del dato “padre” se encuentra en la primera fila y el valor de este dato hay que buscarlo en filas subsecuentes.

• Sinonimo: En caso de que no se encuentre un punto de referencia con la palabra especificado en “Dato”, busca los valores de este elemento para crear los puntos de referencia.

La inclusión del elemento “Sinonimo” se da para cubrir lo que se considera un punto débil en el trabajo [10] de Arasu y García, mencionado en la sección 2.2.4. Los fundamentos para este elemento son los siguientes:

1) Una palabra que sirva para distinguir información en un dominio de datos determinado, puede servir también para otro dominio de datos y es necesario establecer la diferencia, ya que la búsqueda puede arrojar datos pertenecientes a otro dominio. Por ejemplo: En el dominio de partidos de fútbol soccer, la palabra local puede usarse para determinar al equipo cuyo estadio es aquel donde se desarrolla el partido; sin embargo, en el dominio de datos de información fiscal, la palabra significa el lugar donde reside la empresa. Esta situación es un ejemplo del problema “esquema de datos diferentes” mencionado en la sección 2.4.

2) De igual forma, se encuentra que diferentes palabras pueden referirse al mismo elemento [4] y es necesario agregarlas a la estructura de búsqueda inicial. Un ejemplo lo vemos si la búsqueda se realiza en documentos de diferentes idiomas. Este ejemplo se ilustra en el primer caso práctico, en la sección 4.1.

34

3) La búsqueda puede traer datos inválidos para el dominio de datos, no obstante que estén asociados a una misma palabra. Puede ser debido a la no existencia de una separación por tags de HTML, errores de construcción en páginas dinámicas, o incluso localización de palabras del dominio cuando no incluyen datos. Retomando el ejemplo de partidos de fútbol, podemos tener una página donde de antemano se presente información de las jornadas de partidos, sin que éstos se hayan efectuado aún, y por ende no tengan marcadores.

Tomemos el siguiente ejemplo para representar el marcador final de un partido de fútbol

<dato @multiple=”no” @requerido=”si”>local<default>Equipo Local</default><dominio>String</dominio>

</dato><dato @multiple=”no” @requerido=”si”>marcador_local

<default>0</default><dominio>numero</dominio>

</dato><dato @multiple=”no” @requerido=”si”>marcador_visita

<default>0</default><dominio>numero</dominio>

</dato><dato @multiple=”no” @requerido=”si”>visita

<default>Equipo visitante</default><dominio>String</dominio><sinonimo>visita</sinonimo>

</dato>

La estructura considera buscar un resultado de la forma Local Marcador_local – Marcador_visita Visita. Hay que notar lo siguiente en la estructura.

● Ninguno de los atributos es múltiple, solo puede haber una ocurrencia de cada elemento.

● Es frecuente hallar que al equipo visitante, también se le refiere como solamente “visita”, por eso se le agrega como sinónimo.

● Desde el instante que un partido se realiza, los marcadores de ambos equipos empiezan con cero, por eso se define ese valor por defecto.

35

Es común encontrar los resultados de partidos de fútbol en tablas, por esta razón se considera por defecto de que busque por filas. La primera fila contiene los encabezados de la tabla, que en un ámbito de resultados de fútbol soccer indica en la primera columna el equipo local, en la segunda el marcador del local, en la tercera el marcador del equipo visitante y en la última el equipo visitante, aunque esta distribución puede variar, como se aprecia en la figura 3.3:

Figura 3.3. Ejemplo de partidos de fútbol

En el caso del equipo visitante es factible encontrar el indicador ya sea como Visita o como Visitante, como ya se indicó en la definición de la estructura de búsqueda.

Otra observación sobre la figura anterior, es que si bien, en cada renglón de la tabla aparece un partido de fútbol, no aparece un elemento en cada celda. La tercera celda, tiene los marcadores de ambos equipos, cuando en la estructura de búsqueda aparecen como elementos separados.

36

El hecho de tener una estructura de búsqueda definida en lenguaje XML permite representar un dominio de datos de manera genérica. Esto facilita la búsqueda en distintos documentos semi-estructurados, o incluso, permite reutilizar la estructura cuando un documento cambia. Este punto se ilustra en las siguientes figuras:

Figura 3.4. Formato del sitio www.mundosoccer.com antes de septiembre del 2006

Figura 3.5. Formato del sitio www.mundosoccer.com a partir de septiembre del 2006.

La figura 3.4 muestra como se desplegaba la página hasta septiembre del año 2006, la figura 3.5 muestra como se despliega a partir de esa fecha la información de partidos en la misma página. Como se aprecia al comparar ambas figuras, en la figura 3.4 se ve que por cada renglón en la tabla aparece la información de un partido, mientras que en la figura3.5, aparece en una misma celda los partidos realizados en un mismo

37

día. Además, hay que considerar el uso de la palabra “Resultados”, que no existe en el ejemplo de la figura 3.4, pero sí en el ejemplo de la figura 3.5. Las reglas de definición de la estructura de búsqueda, nos permiten la adición de la palabra “Resultados” ya sea como un elemento, o como un sinónimo, de forma que la estructura de búsqueda definida para la página de la figura 3.4, puede adaptarse con la incorporación de ese elemento, para la página ilustrada en la figura 3.5.

Esto contrasta con el trabajo [11], referenciado en la sección 2.2.5. Retomando el uso de la palabra “Resultados”, la cual al no existir en la primera página no generaría algún valor numérico, pero en la segunda sí; y cambiaría las similitudes entre la representación numérica de la estructura de datos a buscar, contra la representación numérica de la página HTML generada, disminuyendo la re-utilización de la representación numérica creada para la página de la figura 3.4.

3.4 Fuente de Datos

La fuente de datos es una página HTML que contiene información sobre el tema que interesa obtener datos, donde dicha página es localizada mediante un URL. La búsqueda de la información se hace siempre sobre la misma página, no se realiza una búsqueda en otras páginas, aun cuando se encuentren en el mismo servidor.

No obstante, hay factores que considerar para elegir la fuente de datos:

1) Confiablidad de la fuente. La fuente debe tener validez dentro del área de dominio de interés. Esto permite veracidad en los datos obtenidos.

2) Periodicidad de los datos. El tiempo que los datos permanecen en la fuente, la frecuencia con la que cambian, o incluso considerar que dichos datos pueden desaparecer en un determinado tiempo.

3) Presentación de los datos. La forma en que los datos aparecen en la fuente, hay que considerar que esta forma puede cambiar con el tiempo.

38

Un factor importante para la elección de la fuente de datos es el propósito del uso de la misma, las situaciones más relevantes se proponen a continuación:

3.4.1 Seguimiento en el tiempo de una misma fuente

En esta situación, la estructura de datos en la página permanece constante, pero los datos cambian de manera periódica, incluso el URL asociado a la página puede cambiar si es una página generada de manera dinámica.

Como ejemplos tenemos el seguimiento de mediciones del clima en una región determinada o estadísticas de un torneo deportivo.

En este escenario hay que responder las siguientes preguntas:

• ¿La fuente es capaz de producir datos confiables a través de una conexión confiable? Definimos como un dato confiable aquel que no cambia de manera frecuente, de acuerdo al usuario de la estrategia y se encuentra validado o respaldado por alguna institución cuya veracidad se considere válida por el usuario de la estrategia. De igual forma, la conexión confiable garantiza que la fuente va a permanecer en la misma dirección URL. Es de considerar la veracidad de la fuente, porque los datos hallados, o la falta de los mismos, influirán en los ajustes que se hagan a la estructura de búsqueda.

• ¿Por cuanto tiempo permanecerá la fuente de datos disponible? En este punto nos referimos al tiempo que la fuente existirá. Es de esperar que un sitio de WWW de una compañía como un periódico de circulación nacional en un país, exista varios años, mientras que si la fuente es un documento que el usuario de la estrategia poseé, no se conoce a ciencia cierta si existen otras copias disponibles de dicho documento, en otras páginas, para el usuario. También influye el tiempo que se realizó el documento, suponiendo una página que predice los resultados de la Copa del Mundo de Futbol, es de esperar que estos datos no estén disponibles una vez que la Copa terminó.

39

• ¿Que tan estable es la estructura de la fuente? Nos referimos en este caso a la frecuencia con que la estructura de los datos cambia, no los datos en sí. Esta situación es la menos frecuente de las mencionadas, pero es importante considerar sobre todo para el seguimiento de una misma fuente en el tiempo. Por ejemplo, una página que hable de fútbol y que ha modificado la forma de desplegar los resultados de partidos. Los datos pueden no cambiar, pero la forma en que se despliegan sí.

3.4.2 Búsqueda de información en distintas fuentes

En esta situación, se buscan los mismos datos, pero en distintas páginas de red. Como ya se ha mencionado, distintas páginas de red pueden mostrar la misma información pero el formato en que se presentan es diferente, por lo que una misma estructura de datos de búsqueda puede ser efectiva en una página; mas no en la otra, eso sin contar la idea de que en ambas páginas el mismo concepto se refiera de manera diferente. Por ejemplo, la terminología de informática usada en España y en México difiere notablemente, una página redactada en el idioma castellano usado en España usará vocablos diferentes a los que usa una página redactada con los vocablos usados en México.

Es requisito que se haya evaluado previamente que la fuente efectivamente contiene alguno de los elementos de la estructura a buscar. En este caso el usuario de la estrategia es quien evalúa la fuente, ya que tiene conocimientos en el dominio de interés de la búsqueda de información. De otra forma, la búsqueda de datos puede arrojar resultados no deseados.

Destaca el conocimiento en el dominio de interés, ya que es el que permite definir la precisión de la estructura de búsqueda. Como se verá en el primer caso práctico, que trata sobre recopilación de datos de béisbol, un dato sumamente importante es el porcentaje de bateo pues es uno de los indicadores principales del desempeño de un bateador. De igual forma, la manera en que se representan la cantidad de entradas que un lanzador lanzó incluye el uso de fracciones de 3, que para un lector no conocedor del dominio de interés, puede resultar incomprensible el uso y significado de dichas fracciones.

40

3.5 Transformación de página de red

El primer paso para realizar una búsqueda de datos en una página red es transformar dicha página en un documento XHTML bien formado, dado que un documento escrito en lenguaje HTML no necesariamente es un documento bien formado.

Al convertir una pagina HTML a un documento XHTML, que es un documento XML bien formado, los datos a buscar pueden estar localizados en dos tags: <div> y <p>, lo que reduce la búsqueda considerablemente, dado que solo se busca información es esos tags en particular. Si bien, es posible incorporar información en otros tags de HTML, al convertirse en documento XHTML, la información queda localizada en alguno de los tags de este tipo. De esta forma, se cumple una observación realizada por Jussi Myllymaki en [1], donde comenta que la información relevante a una aplicación orientada a datos se encuentra localizada en unos cuantos tipos de tags.

En este paso al aplicar la primera transformación XSL, se eliminan los tags de formato tales como <b>, <i> y <li>, cuando estos tags existen se encuentran dentro de los de búsqueda de datos, por lo que se eliminan las marcas de estos tags, pero no su contenido.

Para clarificar el punto, asumamos el siguiente código HTML:

<p> <b> Monterrey </b> 3 – 1 <b> Tigres </b> </p>

Lo cual visto desde un interpretador de lenguaje HTML nos da el siguiente resultado:

Monterrey 3 - 1 Tigres

Donde el tag <b></b> sirve para que el navegador resalta el texto contenido entre dichos tags, pero no influye en los datos. Por eso al aplicar la primera regla de transformación, nos deja lo siguiente:

<p> Monterrey 3 – 1 Tigres <p>

Que no afecta el contenido dentro del tag <p>, pues ese contenido es la información que se va a desplegar en un navegador, aunque sin resaltar, como lo haría con el tag <b>.

41

Para facilitar la localización de elementos en el documento XHTML recién generado, es necesario realizar otra transformación. Es común que los elementos <div> y <p> se encuentren anidados en tablas, de ser así, se les localiza dentro de elementos <td>, que define una celda en una tabla HTML, por lo que es preciso poder ubicar estos elementos dentro del árbol XHTML. La opción para ubicar una celda en una tabla HTML, es agregar dos atributos al tag, dichos atributos no pertenecen a la especificación del tag en el lenguaje HTML, por lo que si el documento se abriere con un interpretador de lenguaje HTML, no afectará la forma en que se despliega.

Además, es necesario limpiar los elementos que no pertenecen a HTML como código de lenguajes JavaScript o PHP. Estos elementos proporcionan funcionalidad a un documento HTML, sin embargo, no contienen información a desplegarse. Si bien estos lenguajes tienen elementos sintácticos no definidos en el HTML, el lenguaje HTML permite distinguir el contenido de dichos elementos, por medio de los tags <script> y <?>.

De igual forma, otro elemento HTML que suele contener elementos de este tipo es el <li> que representa elementos de una lista. Al procesar un documento de lenguaje HTML que posea tags de este tipo, para convertirlo en un documento bien formado, si el tag posee algún contenido este queda dentro de tags <p>, por lo que es factible eliminar el tag <li>, mas no su contenido, de manera similar a la forma de procesar los elementos que afectan el formato de la información.

Recordando el ejemplo del partido de futbol, que se encuentre localizado en una tabla que contiene otros resultados.

<script language=”Javascript”><table border=1><tr> <td><p>Monterrey 3-1 Tigres </p></td> </tr><tr> <td><p>Veracruz 3-0 San Luis </p> </tr></table></script>

42

En un interpretador de HTML se vería lo siguiente:

Monterrey 3-1 TigresVeracruz 3-0 San Luis

Aplicando una transformación XSL, es posible generar coordenadas que ubiquen un elemento <td> como elementos similares a filas y columnas de una hoja de cálculo. Esto se hace con el fin de ubicar un valor de un elemento en la estructura, en caso de que se encuentre.

En el ejemplo anterior, es una tabla donde cada renglón tiene una columna, interpretándolo como una celda de hoja de cálculo. El resultado de Monterrey, está en la celda (1,1) mientras que el resultado del Veracruz está en la celda (2,1).

Otro beneficio de enumerar las tablas, es para abordar una limitante del trabajo “Estructuras similares” [11] mencionado en la sección 2.2.5, la que consiste en la ubicación de los elementos dentro de tablas. Ya que si bien la idea de usar estructuras similares para buscar elementos, repercute en cierto grado de ayuda, el lenguaje HTML permite desplegar de distintas formas una misma información. Por ejemplo, en tablas anidadas dentro de tablas, elementos que se encuentren en una misma celda de tabla debido a desconocimiento del programador, o listas que contienen tablas.

En el ejemplo se puede apreciar una situación. Si el elemento a buscar es solamente el puro resultado en un solo valor, no hay ningún problema, el valor directo del elemento <p> cumple el requerimiento. Pero ¿qué sucede si dentro de un mismo elemento del documento XHTML se puede satisfacer más de un elemento de una estructura de búsqueda?

Esta situación se ve con mayor claridad en el caso práctico “Capturasemi-automatizada de una fuente de datos“, que se abordará en la sección 4.1; y por esta razón se aduce la necesidad de un operador humano que valide la información, pues en este caso, el operador humano puede realizar los ajustes. La solución propuesta en dicho caso práctico es el uso de expresiones regulares, que permitan seccionar la información para almacenar datos encontrados en diferentes elementos de la estructura de búsqueda. Precisamente esta situación es una debilidad considerada en el trabajo “Estrategia “Dividir y Vencer”” [13].

43

Cabe resaltar un aspecto de la intervención de un operador humano en el proceso. Es muy importante la validación de los datos obtenidos, ya que es posible poblar los datos de la estructura de búsqueda, que dichos datos sean válidos desde un punto de vista sintáctico, pero semánticamente no lo sean. El operador humano, es quien provee esa validación final, en caso de que los datos, aunque sintácticamente sean correctos, no lo estén desde un punto de vista semántico.

3.6 Puntos de referencia

Definimos como punto de referencia, a la sección dentro de un elemento que contiene ya sea el valor de un elemento dato, uno de sus sinónimos, o el dominio de datos especificado para el elemento en la estructura de búsqueda. La búsqueda de los puntos de referencia lleva el siguiente procedimiento:

1) Por cada uno de los elementos dato de la estructura de búsqueda, busca el valor especificado dentro de los tags <p> y <div> del documento XHTML. En caso de hallarlo se genera la entrada del documento XSL con la condición de transformación solamente para el dato hallado, de acuerdo al tipo de tag donde se halló. Además, se debe definir que parte del tag es lo que se va a copiar a partir del punto de referencia, definidos en el atributo delimitador del elemento en la estructura de búsqueda.

2) Al procesar el elemento dato y no hallar el valor del elemento, procede la misma función pero buscando por un sinónimo. Esto se repite por cada uno de los sinónimos definidos para el elemento dato, hasta encontrar un sinónimo en los tags del documento XHTML. La iteración se detiene al hallar la primera ocurrencia de los sinónimos, a menos que el valor del atributo multiple sea “sí”. En ese caso se agrega una transformación por cada sinónimo hallado.

3) En caso de no existir tampoco un sinónimo se busca un dominio de datos, que es una representación de las características de un valor que pudiere tener este elemento. Dado que el dominio puede ser representado por expresiones regulares, en ese caso se

44

procede a buscarlo por medio de comandos tales como el sed6. Retomando el ejemplo de equipos deportivos, un nombre de un competidor siempre tendrá por lo menos alguna letra, mientras que los puntajes tendrán por lo menos un número.

4) En caso de que tampoco se haya encontrado una expresión que satisfaga el dominio de datos, y de que el valor del atributo requerido sea “si”, se agrega el valor del elemento default si existe; en caso contrario, se agrega el mismo nombre del elemento.

El resultado de la búsqueda de puntos de referencia es un archivo XSL que aplicado sobre el código del XHTML produce un documento XML, donde cada elemento de la estructura XML corresponde al valor de cada elemento dato del documento de definición de datos, donde los valores de éste son obtenidos por cálculos a partir de los puntos de referencia y definidos por los atributos correspondientes al dato.

Este archivo de transformación es creado por medio de expresiones XPath y XSL que delimitan el contenido alrededor de los puntos de referencia. El ciclo de búsqueda puede realizarse de dos formas:

• Buscar cada elemento de la estructura de datos XML en el archivo XHTML.

• Buscar cada palabra en los tags de búsqueda del archivo XHTML entre los elementos de la estructura de datos XML.

A continuación se describen a detalle ambas aproximaciones para el ciclo de búsqueda de puntos de referencia.

3.6.1 Búsqueda de cada elemento

Esta es la aproximación propuesta en este método. En el caso ideal se tiene un elemento transformador XSL por cada elemento hallado, cuyo valor se obtiene de acuerdo a la definición de los atributos y elementos de la estructura de búsqueda XML. Además permite realizar una métrica de la efectividad de la estructura XML de búsqueda, de acuerdo al número de elementos cuyo valor final fue el valor por defecto definido, 6 El sed es un software que permite automatizar operaciones sobre textos desde una linea de comandos.

45

en caso de que exista el valor de este elemento. Lo cual puede presentar problemas cuando un sinónimo coincide con otro elemento de la estructura de búsqueda, como se muestra en el siguiente ejemplo:

<dato> Fiscal </dato><dato> Ambito <sinonimo> Fiscal </sinonimo> <sinonimo> Mercantil </sinonimo> </dato>

En el documento XHTML se encuentra la ocurrencia del dato “Fiscal”, pero al buscar el elemento Ambito, esta palabra no aparece, pero hallará el elemento Fiscal como sinónimo del elemento Ambito, por lo que la regla de transformación XSL puede arrojar el mismo valor para dos elementos diferentes.

3.6.2 Buscar cada palabra de los tags

En esta aproximación, se busca cada palabra contenida en los tags7, para ver si coincide con algún elemento de la estructura de búsqueda. En este caso, se ignorarían los atributos del dominio. La razón por la que esta aproximación no se consideró es que implicaría hacer más búsquedas en la estructura XML, ya que por lo general la cantidad de elementos “dato” definidos en la estructura de búsqueda, es mucho menor que la cantidad de palabras en el documento XHTML procesado. Este caso también dificulta el poder definir de manera adecuada si hay ocurrencias múltiples de un mismo elemento “dato”.

3.6.3 Mapeo de puntos de referencia a la estructura de datos

A partir de cada punto de referencia, podemos crear el código que actualmente extraerá los datos. El código es básicamente un archivo de tipo XSL. El propósito del archivo es identificar el punto de referencia, especificar como obtener los datos que estamos buscando y construir el XML especificado en la estructura de datos.

La metodología automatizada debe generar el archivo XSL al que nos referimos en este punto. En caso de no hallar un valor para un elemento

7 Existe una lista de palabras a ignorar, tales como proposiciones y artículos. Se trabaja sobre aquellas palabras que no estén en esta lista.

46

especificado, se llena con el valor default del elemento en caso de que este definido, en el caso de usar el algoritmo especificado en la sección anterior.

Si el elemento no pertenece a un tag <td>, quiere decir, dentro de la celda de una tabla. El valor que será asociado al elemento se obtiene de copiar todos los caracteres a la derecha de la palabra encontrada hasta que termine el valor del tag.

En caso contrario se pueden proceder de dos formas:

• Por defecto los valores del elemento se encuentran localizados de manera vertical. Es decir, uno o más valores del elemento se encuentran en la misma columna donde se determinó el punto de referencia, pero en las filas que se encuentran posteriores a éste. Un ejemplo es las tablas de posiciones en un torneo deportivo de conjunto como fútbol o béisbol.

• Por defecto los valores del elemento se encuentran localizados de manera horizontal. Es decir, en la celda contigua a la derecha de la celda donde se ubicó el punto de referencia del elemento se encuentra el valor del mismo.

La corrida por defecto se hace asumiendo que los valores se encuentran de manera vertical, en caso de que el usuario extractor de información determine que los valores no son adecuados, puede intentarse una segunda corrida especificando que sea de manera horizontal.

Como se mencionó en la sección anterior, se presenta una situación cuando un mismo tag contiene valores que satisfacen a más de un elemento. Se propone que dentro del tag se busquen espacios en blanco para delimitar valores. También es posible auxiliarse de expresiones regulares, como fue en el caso practico de los datos de béisbol.

Esta situación conlleva a efectuar varias iteraciones de los pasos sugeridos en esta estrategia. Estas iteraciones pueden tener propósitos diferentes, aunque no mutuamente excluyentes.

1) Actualizar tanto la estructura de búsqueda, como las expresiones regulares a buscar, con el fin de obtener valores que

47

se adapten mejor a la estructura de búsqueda.

2) Realizar validaciones posteriores a la captura, que ocurre cuando la fuente no tiene todos los delimitadores de los datos. Esto se explica con mayor detalle en la sección 3.6.1.

3) Adaptarse a cambios no previstos o situaciones donde aparecen valores que no se consideran en el dominio original. Como la aparición de caracteres alfanuméricos en un campo que por definición solo lleva caracteres numéricos.

3.7 Conclusiones

Al considerar los trabajos enumerados en el capítulo 2 del trabajo así como los pasos descritos en este capítulo, se proponen los siguientes beneficios de esta estrategia de extracción:

1) Flexibilidad al buscar en fuentes donde la misma información de un dominio de datos se encuentra agrupada de maneras diferentes. La inclusión del manejo de sinónimos permite esto, pues facilita la búsqueda en estructuras diferentes al buscar por un término alterno que represente lo mismo en caso de no hallar el término original.

2) Considerando la expansión del uso de formatos bien formados o semi-estructurados para almacenar información además de presentarla, el hecho de que el resultado de la aplicación de la estrategia sea una estructura bien formada permite la creación de una amplia variedad de aplicaciones que pueden explotar esta estructura. Como ejemplos tenemos la propuesta de formato Open Document, así como los formatos de XML propuestos también por la empresa Microsoft.

3) Permite reducir el tiempo de alimentación de una base de datos partiendo de documentos que tengan la información que va a residir en dicha base de datos.

Estos beneficios se explican con más detalle en los siguientes capítulos, sobre los casos prácticos, las aportaciones y aplicaciones sugeridas.

48

Capítulo 4. Casos Prácticos

Para probar la estrategia se seleccionaron dos casos prácticos que abarcan dos aplicaciones distintas. El primero de los casos es captura masiva de registros que tienen una misma estructura para alimentar una base de datos. El segundo es el seguimiento en el tiempo de una misma fuente de datos para realizar un estudio prospectivo en un área de interés determinada.

Para cada caso se explican los pasos descritos en el capítulo anterior. Se explica a detalle aquellos pasos en los que fue necesario hacer algún ajuste a la estructura de búsqueda.

4.1 Captura semi-automatizada de una fuente de datos

Este caso consiste en transformar la información referente a estadísticas de jugadores de béisbol, contenida en el documento “Enciclopedia del béisbol Mexicano 2005”, a una base de datos. Posteriormente se probará la estructura de búsqueda generada para este documento con una página de red que contenga información similar, el sitio en cuestión es www.baseball-reference.com.

Para estos ejemplos, la información contenida en ambas fuentes de datos, abarca información utilizada para medir el desempeño de jugadores de béisbol en un determinado torneo. La primera fuente, la Enciclopedia del béisbol Mexicano, abarca solamente jugadores de la Liga Mexicana de Béisbol, mientras que el sitio de red abarca jugadores de las ligas de Estados Unidos de Norteamérica, llamadas también Ligas Mayores.

Las estructuras usadas para la extracción se pueden observar en Apéndice A. Dichas estructuras abarcan los dos grupos en que se pueden dividir los jugadores de béisbol: bateadores y lanzadores.

49

4.1.1 Definición de estructura de búsqueda

Las estructuras de datos se basaron en el libro “Quien es quien en el béisbol mexicano” del año 2000. El hecho de basar la estructura en una fuente en particular, repercutió de manera notable en el resto del caso.

Dada la naturaleza de la información de béisbol, que se manejan dos grupos de datos diferentes de acuerdo al tipo de jugador: bateador o lanzador, que en la actualidad casi en su totalidad son mutuamente excluyentes. Se optó por usar dos estructuras XML para guardar los datos.

Un lanzador ya no batea, por lo tanto, no se guarda información a su desempeño como bateador, salvo en ocasiones muy contadas. En particular, el documento de la “Enciclopedia del béisbol Mexicano 2005” no guarda la información de estadísticas de bateo de la mayoría de los lanzadores, aun cuando estos bateaban en temporadas anteriores a 1976.

4.1.2 Fuente de Datos

La primera fuente de datos es el documento PDF “Enciclopedia del béisbol Mexicano 2005”. Dicho documento fue utilizado con permiso de la Liga Mexicana de Béisbol. Este libro tiene estadísticas de todos los jugadores que han participado en dicha liga hasta el año 2005.

La segunda fuente de datos es cualquier consulta de los datos de un jugador en la página www.baseball-reference.com que contiene información de los jugadores de béisbol que actualmente juegan en las Grandes Ligas de los Estados Unidos.

4.1.3 Transformación de página de red

La información se copió de un documento semi-estructurado HTML, obtenido a traves de transformar el archivo PDF, en un documento equivalente en lenguaje HTML. Dado que la información sobre bateadores aparece primero en el documento, fue la primera en procesarse.

50

Figura 4.1. Datos de bateador de béisbol.

Como se ve en la figura 4.1, al principio de cada página de estadísticas de bateadores viene un encabezado, seguido posteriormente de los datos de uno o más jugadores, sin que dicho encabezado aparezca entre jugador y jugador.

La primera dificultad se presentó al transformar el documento PDF a un documento HTML, esperando obtener una tabla en código HTML, en su lugar, cada renglón generó un elemento paragraph de HTML. Considerando los datos de la primera temporada del primer jugador en la figura 4.1 como ejemplo:

<p>ABAD JAIME B:D/R T:D/R Nació/Born:04/ Oct/ 1926 en/in:YANGA, VERACRUZ MEXICO P:OF</p>

<p>1952 AGUILA .222 73 198 30 44 57 5 4 0 15 2 * 1 14 * 17 4 * 0 .288</p>

Por la aplicación de la estrategia se esperaba encontrar en un elemento <td> de HTML una relación directa con uno de los elementos de la estructura XML de búsqueda, pero al no ser el caso, hubo que realizar un trabajo previo de transformación no contemplado que consistió en transformar los datos en una tabla que cumpliera con los requisitos del standard HTML donde los datos se encuentren separados por celdas.

En este caso fue necesario recurrir al uso de expresiones regulares para determinar la separación de datos. El encabezado de cada página

51

se utilizó solamente una vez, para determinar en que columna debería quedar el dato a buscar. Aprovechando que los nombres de los datos también venían mencionados en inglés, se agregaron como sinónimos.

Por cada jugador se observó que el primer renglón contenía datos generales del jugador y los renglones posteriores contenían los datos que varían año con año, de acuerdo a lo realizado en las temporadas en que el jugador tuvo actividad. En el primer renglón de datos del bateador es fácil observar que siempre comienza con su nombre en mayúsculas y cada dato posterior viene precedido de dos puntos, por lo que al alimentar las expresiones regulares de que sustituyese cada palabra que terminase con dos puntos por un separador de etiqueta adecuado, en este caso la etiqueta <tr> de HTML, que representa un renglón dentro de una tabla. Las expresiones regulares usadas para la transformación de cada dato general del jugador en un renglón de una tabla en código HTML fueron las siguientes8:

s/\(^[A-Z]*\)\( \{2,}\)\(.*\)/<td>\1 \3/gs/ [A-Za-z\/]*:/<\/td><td>/gs/\(^\)\(.*\)\($\)/<tr @tipo=”general”>\2<\/td><\/tr>/g

La primera expresión se encarga de localizar el nombre, que siempre va al inicio y además está en mayúsculas, éste será la primera columna de cada renglón, al final de dicho nombre se le agrega un espacio en blanco. Esto fue importante para poder aplicar la siguiente expresión regular.

Se observa que cada indicador de dato se encuentra separado por un espacio en blanco, un número variable de caracteres alfanuméricos y el caracter de dos puntos. La segunda expresión regular transforma esos patrones en patrones de columnas en tabla de HTML, salvo al último dato. De esto se encarga la última expresión que complementa los tags de <tr> que son los que definen un renglón de tabla en código HTML. Se observa que se agrega un atributo tipo que no es propiamente de lenguaje HTML pero que será útil en las futuras transformaciones.

En los renglones de datos del bateador, se observa que después del nombre del equipo viene un porcentaje que siempre empieza con un punto decimal. A partir de este punto cada dato se encuentra separado por un espacio en blanco, por lo que se transformó cada espacio en

8 La aplicación de las expresiones regulares fue por medio de la herramienta sed corriendo sobre Linux Ubuntu 6.0

52

blanco en un separador <td> de lenguaje HTML. Las expresiones regulares usadas para la transformación de estos datos fueron las siguientes:

s/\(^[0-9]\{4\}\)\( \)\([- A-Z]*\)/<td>\1<\/td><td>\3/gs/\( \)\([.*0-9]*\)/<\/td><td>\2/gs/\(^\)\(.*\)\($\)/<tr @tipo=”dato”>\2<\/td><\/tr>/g

La primera expresión se encarga de separar la temporada y los equipos para los que jugó el pelotero, dado que hay equipos de béisbol cuyo nombre consiste de más de una palabra, como en el caso de Nuevo Laredo. Para separar el resto de los datos se observó que con que fuera un espacio en blanco seguido de cualquier caracter distinto a una letra, se hacía la separación. La última expresión se encarga de construir el renglón de una tabla, donde como en la tabla de los datos generales maneja un atributo que permite distinguir el tipo de renglón.

Tomando como ejemplo la primera temporada del primer jugador cuyos datos aparecen en la figura 4.1, el XHTML generado tiene la siguiente forma:

<tr @tipo=”general”><td>ABAD JAIME</td><td>D/R</td><td>D/R</td><td>04/ Oct/ 1926</td><td>YANGA, VERACRUZ MEXICO</td><td>OF</td>

</tr><tr @tipo=”dato”>

<td>1952</td><td>AGUILA</td><td>.222</td><td>73</td><td>198</td><td>30</td><td>44</td><td>57</td><td>5</td><td>4</td><td>0</td><td>15</td><td>2</td><td>*</td><td>1</td><td>14</td><td>*</td><td>17</td>

53

<td>4</td><td>*</td><td>0</td><td>.288</td>

</tr>

Los datos de los lanzadores se presentan de la figura 4.2:

Figura 4.2. Datos de lanzador de béisbol

En particular el dato IP presentó dificultades al incorporar la información a la base de datos, lo cual se explica en la sección 4.1.5 Copiado de información a la base de datos. Se usaron los mismos criterios utilizados con los bateadores para crear los separadores en lenguaje HTML.

Otro elemento de datos que presentó problemas fueron los elementos que empiezan a registrar datos a partir de un determinado año, pero no antes. En la figura 4.2 se puede apreciar en los datos del lanzador José Peña, que previo a la temporada de 1973 no se registran datos de tres elementos, pero en el documento aparecen con asteriscos, aún cuando los valores válidos del dato a nivel conceptual son numéricos. Esto también puede apreciarse en otros elementos de los datos de bateadores.

54

4.1.4 Puntos de referencia

Concluidas las transformaciones hacia un formato de tabla HTML, procede la construcción de los puntos de referencia. En este caso enumerar cada celda de acuerdo a su posición en la tabla. Esto se logró con apoyo del siguiente archivo en formato XSL:

<?xml version="1.0" encoding="ISO-8859-1"?><xsl:stylesheet version="1.0"

xmlns:xsl="http://www.w3.org/1999/XSL/Transform"><xsl:output method="text" indent="yes" />

<xsl:template match="table">&lt;table&gt;<xsl:apply-templates select="tr"/>&lt;/table&gt;

</xsl:template>

<xsl:template match="tr">&lt;tr tipo="<xsl:value-of select="@tipo"/>"&gt;<xsl:apply-templates select="td"/>&lt;/tr&gt;

</xsl:template>

<xsl:template match="td">&lt;td columna="<xsl:number/>"&gt;<xsl:value-of

select="."/>&lt;/td&gt;</xsl:template>

</xsl:stylesheet>

Una vez obtenidas las coordenadas de cada celda, se aplicó la estrategia sobre la primera línea de los datos que contiene los encabezados de donde está colocada la información. La iteración sobre los datos de los bateadores arrojó los datos correctos, es decir, cada elemento se encontró en la columna esperada, como el equipo en la segunda columna. Este es un extracto del XSL elaborado:

<?xml version="1.0" encoding="ISO-8859-1"?><xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"><xsl:output method="text" indent="yes" />

<xsl:template match="table"> &lt;Jugador&gt;

<xsl:apply-templates select="tr"/>&lt;/Jugador&gt;

</xsl:template>

55

<xsl:template match="tr"><xsl:choose><xsl:when test="@tipo='general'">&lt;/Jugador&gt;&lt;Jugador&gt;

<xsl:apply-templates select="td"/></xsl:when><xsl:otherwise>&lt;Datos&gt;

<xsl:apply-templates select="td"/>&lt;/Datos&gt;</xsl:otherwise></xsl:choose>

</xsl:template>

<xsl:template match="td"><xsl:choose><xsl:when test = "../@tipo='general'">

<xsl:choose><xsl:when test="@columna=1">

&lt;Nombre&gt;<xsl:value-of select="."/>&lt;Nombre&gt;

</xsl:when><xsl:when test="@columna=2">

&lt;Lado de bateo&gt;<xsl:value-of select="."/>&lt;Lado de bateo&gt;

</xsl:when><xsl:when test="@columna=3">

&lt;Tira&gt;<xsl:value-of select="."/>&lt;Tira&gt;</xsl:when><xsl:when test="@columna=4">

&lt;Fecha de nacimiento&gt;<xsl:value-of select="."/>&lt;Fecha de nacimiento&gt;

</xsl:when><xsl:when test="@columna=5">

&lt;Lugar de nacimiento&gt;<xsl:value-of select="."/>&lt;Lugar de nacimiento&gt;

</xsl:when><xsl:when test="@columna=6">

&lt;Jugador&gt;<xsl:value-of select="."/>&lt;Jugador&gt;

</xsl:when></xsl:choose>

</xsl:when><xsl:when test = "../@tipo='datos'">

&lt;td columna="<xsl:number/>"&gt;<xsl:value-of select="."/>&lt;/td&gt;

</xsl:when></xsl:choose>

</xsl:template>.....</xsl:stylesheet>

56

Pero se presentó una ambigüedad en la tabla de lanzadores. Como se puede observar en la figura 4.2, la columna de IP en realidad abarca dos columnas en muchos renglones, mas no en todos. Esto es debido a que en la nomenclatura de la Enciclopedia del Beisbol Mexicano, cuando un lanzador no obtuvo los tres bateadores considerados “out”, se representa con fracciones de 3, pero en caso contrario, no se pone valor alguno. La forma de manejar este dato en particular se detalla en la siguiente sección.

La salida de la aplicación fueron documentos XML de la estructura de búsqueda conteniendo los datos que existían previamente en cada renglón. Retomando el ejemplo del bateador Jaime Abad:

<Jugador><Nombre>ABAD JAIME</Nombre><Lado de bateo>D/R</Lado de bateo><Tira>D/R</Tira><Fecha de nacimiento></Fecha de nacimiento><Lugar de nacimiento>YANGA, VERACRUZ, MEXICO</Lugar de

nacimiento><Posición>OF<Posición><Datos>

<Año>1952</Año><Equipo>AGUILA</Equipo><PCT>.222</PCT><Juegos>73</Juegos><Veces al bat>198</Veces al bat><Carreras Anotadas>30</Carreras Anotadas><Hits>44</Hits><Total de bases>57</Total de bases><Dobles>5</Dobles><Triples>4</Triples><Homeruns>0</Homeruns><Carreras Producidas>15</Carreras Producidas><Sacrificios>2</Sacrificios><Elevados de Sacrificio>*</Elevados de Sacrificio><Golpeado>1</Golpeado><Bases por bola>14</Bases por bola><Bases intencionales>*</Bases intencionales><Ponches>17</Ponches><Bases Robadas>4</Bases Robadas><Intentos de robo>*</Intentos de robo><Bateo para Doble play>0</Bateo para Doble play><Slugging>.288</Slugging>

</Datos>....</Jugador>

57

Solo se muestra un extracto por fines de ejemplificación.

4.1.5 Copiado de información a la base de datos

Una vez obtenidos los documentos XML por cada letra de bateadores y lanzadores se procedió a insertar la información en la base de datos. El diseño de la base de datos contempla las siguientes tablas:

a) Tabla de datos de cada jugador. Se guarda el nombre, lugar de nacimiento y posición.

b) Tabla de datos de bateador. Cada registro contiene el desempeño de un bateador por año.

c) Tabla de datos de lanzador. Cada registro contiene el desempeño de un lanzador o pitcher, por año.

Se diseñaron documentos XSL que permitieran la transformación de cada documento XML hacia la tabla que debe guardar. Cada renglón será un registro de la tabla donde cada columna será separada por el símbolo “|” para facilitar su importación en una hoja de cálculo para manipulaciones posteriores.

La primera dificultad se encontró al guardar los nombres de los jugadores, pues un requerimiento de la tabla es que el nombre se almacena en tres campos: nombre, apellidos y apodo. La estructura original guarda todo el nombre en un solo elemento. Esta diferencia entre la estructura de búsqueda y el diseño en la tabla de la base de datos fue hecho a propósito, ya que es un escenario común en aplicaciones reales. La separación no puede hacerse de manera automática ya que existen los siguientes casos:

a) Se guarda un nombre de una palabra y un apellido, este es el caso más frecuente. Ejemplo: Alvaro Abreu.

b) Se guarda un nombre de más de una palabra y un apellido. Ejemplo: Cesar Octavio Alvarez.

c) Se guarda un nombre y dos apellidos. Ejemplo: Winston Llenas Dávila.

58

d) Apellidos compuestos. Ejemplo: Domingo Cruz de la O.

e) Existe un apodo intercalado. Aunque estos se pueden distinguir por el uso de las comillas y van al final, se consideran un caso diferente a los anteriores. Ejemplo: José Peña “Peluche”.

En este caso es necesaria la intervención humana para determinar donde existe la separación correcta de los nombres. La aproximación que se utilizó fue el colocar en una hoja de cálculo los renglones de los datos de los jugadores, para poder facilitar la separación de nombres y apellidos. La separación de los mismos se realizó usando fórmulas con manipulación de strings, colocando la última palabra como nombre. Fue necesario recurrir a modificar fórmulas en casos con apellidos sumamente comunes como González o Pérez, debido a que en muchas ocasiones venían junto con el apellido materno.

La segunda dificultad se encontró con el dato de lanzadores IP. Dicho dato guarda el número de entradas que un lanzador participó en la temporada, donde una entrada puede expresarse en tercios, debido a esto, puede contener valores numéricos enteros o incluir fraccionarios. Por ejemplo, para un año en particular, puede contener el valor “17”, pero para otro puede contener “6 1/3”.

Al crear los documentos de datos de lanzadores, la información variante de dicho dato presentó desfaces; es decir, hubo registros que tenían más columnas de las que la tabla admitiría, esto fue debido a que en los casos donde el dato IP contenía fracciones, las fracciones quedaron en otra columna. El uso de un programa de manipulación de hojas de cálculo permitió acomodar las columnas de manera adecuada.

4.1.6 Comparativo con segunda fuente de datos

Una vez que se probó el proceso con la primera fuente de datos, se procedió a probar la estructura de búsqueda con la segunda fuente de datos, la página www.baseball-reference.com.

Este servidor almacena información de todos los jugadores que han participado en la liga de béisbol de Estados Unidos. Dado que es el mismo dominio de datos, debe almacenar el mismo tipo de información,

59

con los mismos campos, tanto para bateadores como lanzadores. Por esa razón se pensó en tomarlo como segunda fuente de datos, para detectar carencias en la estructura de búsqueda original. Un ejemplo de los datos desplegados para un jugador se aprecia en la figura 4.3.

Figura 4.3. Imagen del sitio www.baseball-reference.com

Hay que notar dos diferencias importantes entre ambas fuentes de datos:

1) Los documentos están presentados en dos formatos diferentes, el primero siendo un documento codificado en formato PDF, el cual hubo que transformar a un documento HTML.

2) Los documentos se encuentran en idiomas diferentes. El primero en español, el segundo en inglés. No obstante que la fuente 1 proveé en el documento PDF equivalentes en inglés a los nombres de los elementos desplegados, al transformarse al documento HTML solo se manejaron los nombres en español.

El primer paso fue agregar los sinónimos de los datos en inglés, pero

60

se presentó una dificultad. En algunos casos se encontró que los sinónimos en inglés correspondían a elementos ya existentes, por ejemplo, en la estructura de datos de lanzadores, ya existía el elemento “Ganados” con el sinónimo “G”, de igual forma existe el elemento “Juegos”, cuyo sinónimo en inglés es una “G”. Esto presenta un problema dado que el proceso asignó el valor que considere pertenezca a una “G” a la primera ocurrencia dentro de un elemento o sinónimo que encuentre en la estructura.

En el caso práctico solo ocurre con ese elemento en particular. Es posible manejar subconjuntos de sinónimos, pero es válido encontrar que en distintos documentos de datos sobre un dominio de información, uno de los documentos maneje los elementos definidos en la estructura de búsqueda, mientras que el otro utilice una mezcla de elementos con sinónimos. Esta es la razón por la que el buscador asigna el valor que encuentra a la primera ocurrencia dentro de la estructura de búsqueda.

Al agregar los sinónimos a la estructura de búsqueda se observó que existen elementos que tienen la misma etiqueta en ambos idiomas, como los valores de los campos Hits (H) y Base por Bolas (BB)9. En estos casos no se agregó otro sinónimo al elemento.

4.1.7 Observaciones del caso práctico

La tabla de datos de jugadores, incluyendo bateadores y lanzadores, contiene un total de 6820 registros. La tabla de datos de bateadores contiene un total de 14237 registros. La tabla de datos de lanzadores contiene 10373 registros. Toda esta información se capturó en un total de 60 horas utilizando la estrategia propuesta en esta tesis, de las cuales 5 horas se usaron para el diseño de las expresiones regulares y los documentos de transformación XSL y 15 fueron dedicadas a la manipulación posterior de información.

Se realizó una prueba capturando manualmente una página, que contenía información de 13 jugadores, donde había un total de 63 renglones de datos. Capturar manualmente esa información llevó aproximadamente 50 minutos. En el documento original la información de bateadores y lanzadores se encuentra repartida en 370 páginas.

9 En inglés el término es “Base for Balls” que también se abrevia como BB.

61

En el caso de la segunda fuente de datos, no se procedió a hacer un llenado de todos los datos hacia la base de datos debido a que implicaría manualmente ir sobre cada jugador de cada año de cada equipo, donde de los treinta equipos que en la actualidad participan en Major League Baseball, dieciseis han participado en cien campañas. Dado que no es el objetivo de trabajar sobre esa fuente de datos para llenar una base de datos, si no el ver como se comportaba con la estructura de búsqueda existente.

En este caso se encontró que para el caso de los bateadores había un campo que no se encontraba en la primera fuente, de igual forma también apareció un dato de lanzadores ausente en la estructura de búsqueda pertinente a éstos.

Otro detalle fue que en el segundo documento no era posible encontrar una limitante entre la fecha y el lugar de nacimiento, que en el primer documento se presentaban perfectamente delimitados, en este caso se presentaban juntos por lo que el valor se asignaba al sinónimo en inglés.

4.2 Seguimiento en el tiempo de una fuente de información

Este caso consiste en capturar información de una misma fuente, pero en distintas etapas en el tiempo. En particular se registrarán datos de un mes de una página de red10 que contiene el clima de la ciudad de Monterrey.

La finalidad de este caso es probar si la estrategias propuesta, aplica en un escenario donde el objetivo es obtener datos a través del tiempo de una misma fuente de datos. Las diferencias con el caso anterior son las siguientes:

1) Se eligió un tema del cual el autor no domina. Con el fin de determinar la influencia del conocimiento del área de dominio de datos, en la realización de la estructura de datos y de las adecuaciones que fuere necesario hacer a la misma.

10 La página en cuestión es http://weather.cnn.com/weather/forecast.jsp?locCode=MMMY

62

2) La información de la fuente cambia con una periodicidad bien definida, a diferencia del caso anterior donde la información permanece constante. Por cambios, nos referimos a que si en un día se consulta la fuente, presenta una información determinada, pero si se consulta en una fecha posterior, presenta otra11.

4.2.1 Definición de la estructura de búsqueda

Debido al poco conocimiento del área de conocimiento, se optó por una estructura de búsqueda que solo contiene tres datos:

1) Temperatura. Posee un delimitador en el caracter “°”, que en HTML se representa como “&deg;”.

2) Humedad. No se conocen las unidades en que se mide.

3) Viento. No se conocen las unidades en que se mide.

Todos los datos son numéricos. Es de destacar que salvo en el caso de la temperatura, no se conocen las unidades de medición de los otros elementos; por ende, hay desconocimiento de delimitadores que pudieran ayudar a localizar adecuadamente los valores que cumplan dichos elementos, en el caso de que la estructura de presentación de la fuente de datos llegare a cambiar.

Aún en el caso de la temperatura, que se conoce el delimitador, no se consideró que la temperatura tiene más de un sistema de medición, donde dichos sistemas usan el mismo delimitador, pero requieren otro elemento para poder distinguir un sistema de medición del otro.

4.2.2 Fuente de datos

El documento de HTML que muestra la información, varía con frecuencia diaria; es decir, cada día, la información suele ser diferente. Además, en este sitio, no cambia la forma de llegar al documento que contiene la temperatura de la ciudad que se desea monitorear. Aunque aparecen temperaturas de días anteriores, la temperatura del día en que 11 Esto no quiere decir que la información de fechas anteriores a la consulta cambie. El cambio solo se da al

consultar la página en cuestión, no al consultar sobre resultados anteriores.

63

se consulta la página es la primera en encontrar, si se hace un recorrido desde el inicio del documento.

La sección del documento que contiene los datos referentes al día en que se realiza la consulta no varía y contiene los datos definidos en la estructura de búsqueda. Al no tener cambios en el formato de presentación, no es necesario realizar ajustes y modificaciones a la estructura de búsqueda. Se puede apreciar, en la figura 4.4 una muestra de la página HTML que cumple la función de fuente de datos para este caso.

Figura 4.4. Reporte de clima de la página weather.cnn.com

Al ver la figura 4.4 se aprecian los siguientes puntos:

1) La estructura de búsqueda se realizó en idioma español y la

64

fuente de datos se encuentra en idioma inglés, por lo que fue necesario agregar sinónimos para localizar los datos.

2) La página muestra dos datos de temperatura, en distintos sistemas de medición. Dado que no puede haber dos temperaturas diferentes al mismo tiempo, para una ciudad, la estructura solo considera guardar la primera ocurrencia de la temperatura. Dentro de este punto, los datos guardados en la base de datos son en grados Fahrenheit, por ser de la primera ocurrencia, pero ese dato llevado tal cual a grados Centígrados, es un valor inválido para temperaturas en una ciudad.

Esta página de HTML, obtiene los datos a desplegar de una base de datos, la cual es inaccesible de manera directa al usuario que utiliza el navegador de internet. La interfaz que el servicio provee al usuario es esta página, dado que el usuario no tiene acceso directo a las tablas que guardan la información en el servidor.

4.2.3 Transformación de página de red

El mismo día la página puede presentar contenido diferente, de acuerdo a la hora en que se consulte, esto es debido a que conforme pasa el día, la temperatura puede variar. Por ejemplo, un día que amanece soleado, pero se nubla hacia la tarde, lo que genera datos diferentes.

El documento contiene mucho código de lenguaje JavaScript y de estilo CSS, lo cual es cada vez más frecuente de hallar en páginas. Este código se elimina con la primera transformación con documentos XSL, que se encarga de quitar este tipo de código, eliminando todo el código de JavaScript y CSS, dejando solo los tags a buscar <td> y <p>, en un formato XHTML.

Sin embargo, en la página la información también se encuentra dentro de tags <span>. Esto se detectó tras constatar en la primera corrida que no arrojó datos a buscar. En ese caso, hubo que modificar el transformador de XSL para que conserve el valor de los tags <span>. El código que contiene la información es el siguiente:

65

<span style="font-family:arial;font-size:30px;font-weight:bold;">68&deg;F</span><BR><span style="font-family:arial;font-size:12px;font-weight:bold;">(20&deg;C)</span>...Rel. Humidity: <b>77%</b><BR>Wind: <b>SSE at 4 mph (6 km/h)</b><BR>...

Dado que se considera buscar para la temperatura, una palabra consistente de uno o más números seguidos de la expresión “&deg;”, hay dos tags <span> que se conservan porque contienen palabras que cumplen con ese patrón. Se puede consultar en el apéndice la estructura de búsqueda.

4.2.4 Puntos de referencia

El hecho de que los valores del elemento dato estuvieran contenidos a su vez en otros tags de formato no presentó problema pues el proceso limpia los tags de formateo, pero no el dato al cual están aplicando el formato.

Sin embargo, se presentó la siguiente situación. La temperatura aparece en dos mediciones: grados Fahrenheit y grados Centígrados. El documento XSL arroja los datos en grados Fahrenheit, pues eran los primeros que cumplían con el requerimiento del delimitador de la información. De acuerdo a la descripción de la estrategia propuesta en este documento, se pueden realizar varias adecuaciones para lidiar con la situación de dos temperaturas:

1) Modificar la estructura de datos para que permita almacenar dos temperaturas.

2) Modificar el dominio de datos del elemento “Temperatura” para que solo considere valores de uno de los sistemas, ya sea el Fahrenheit o el Centígrado, al agregar una F o C al final del patrón de búsqueda.

Se optó por manejar todo en grados Fahrenheit, porque el objetivo de evaluar este caso es la extracción de una temperatura, para guardarla en una base de datos, sin especificar el significado o uso que pudieran tener los datos obtenidos. Este tipo de operación sería parte de la

66

explotación que se haría sobre la información obtenida.

En el tiempo de seguimiento de datos de la página, que abarcó el mes de septiembre de este año, no se presentaron cambios en la forma de presentación de datos.

4.2.5 Copiado de información a la base de datos

Después de que el documento XML que satisface la estructura de búsqueda fue generado, se le aplica otra transformación XSL para dejarlo en un formato de ambos datos en un renglón separados por el caracter “|” para su inserción en la base de datos.

El objetivo del caso, solo era almacenar los datos extraídos, independientemente del significado o aplicación que puedan tener estos datos en un futuro. Es más frecuente encontrar escenarios donde se tiene definida la aplicación final de la información extraída, para los datos extraídos en este caso en particular, hay que considerar el caso de la temperatura almacenada en grados Fahrenheit. Una opción puede ser el convertir la temperatura a grados Centígrados antes de almacenarla en la base de datos.

Una pregunta que surge en esta situación es: ¿Se debe incluir en esta estrategia de extracción de datos el procesamiento de datos obtenidos?. Considerando el contexto del trabajo, se responde que no, pues el objetivo es la extracción de información y que esta sea válida dentro de un dominio de datos determinado. En este caso en particular, el valor extraído es una temperatura válida, independientemente del sistema de medición en que está expresada; ya si una aplicación requiere procesar esa medición hacia otro sistema, está fuera del alcance de este proyecto.

4.2.6 Observaciones del caso práctico

La estructura de búsqueda siempre arrojó los mismos datos, ya que aunque los datos en cuestión variaban, su ubicación no.

67

Hay que constatar que este caso se aprecia la sensibilidad a un cambio en el documento fuente de la información, ya que si la estructura incluye palabras no consideradas en la estructura de búsqueda, no podrán encontrarse los datos. Esto puede aplicar a cualquier intento de extracción de datos de documentos semi-estructurados.

Por eso es importante que el encargado de definir la estructura de búsqueda conozca el dominio de datos en el que se basa dicha estructura. De esta forma, es posible agregar sinónimos a los elementos para que la búsqueda pueda lidiar con cambios en la presentación de los datos.

El tiempo de captura de la información por el proceso es de segundos, mientras que el teclear manualmente la información de la página en una base de datos, redituó en 2 minutos. Si bien, no se puede argumentar una diferencia significativa de tiempo como en el caso anterior, se argumenta el beneficio de que, para el caso de almacenar distintos datos en el tiempo, de una fuente de datos, la estrategia provee el beneficio de una automatización relativamente sencilla.

4.3 Conclusiones

Ambos casos sirvieron para mostrar aplicaciones de la estrategia de extracción de datos propuesta en este documento. De acuerdo a lo observado en los casos, se destacan los siguientes puntos:

1) La utilización de una estructura de búsqueda en formato XML, permitió la facilidad de probar esa estructura con fuentes de datos que difieren, desde el idioma en que muestran los datos, a la forma en que éstos se muestran a la persona que acceda a ambas fuentes.

2) De igual forma, la utilización del formato XML, como una estructura común a aplicaciones, facilitó la alimentación de los datos obtenidos en ambos casos a las bases de datos que almacena la información extraída.

3) El conocimiento en el dominio de datos influye de manera

68

importante para la construcción de la estructura de búsqueda. Esto permite la anticipación y conocimiento de elementos que pueden servir como puntos de referencia en los documentos a buscar. En ambos casos, fue necesario hacer ajustes y cambios a las estructuras de búsqueda, ya fuera debido al hallazgo de elementos no previstos, o al desconocimiento del dominio de interés.

4) Para el caso de la captura masiva de registros provenientes de una fuente (el primer caso práctico) la estrategia probó ser una alternativa a considerar, pues permitió alimentar 14237 registros de datos de bateadores y 10373 de lanzadores, en un total de 60 horas, considerando que 63 registros se capturaron en media hora.

5) Para el caso del seguimiento en el tiempo de una misma fuente de datos (segundo caso práctico), donde el objetivo era guardar los datos conforme van cambiando, también se contempla como una alternativa donde se desea tener un proceso que capture datos de manera periódica de una misma fuente, considerando una automatización de ese proceso.

69

Capítulo 5. Aportaciones y Trabajo Futuro

El alcance de la estrategia expuesta en este trabajo propone el uso de una estructura de búsqueda, en forma de un documento XML bien formado como un repositorio para recibir datos extraidos de documentos semi-estructurados, como páginas HTML, con el fin de alimentar una base de datos relacional para que el usuario final pueda realizar explotaciones sobre dicha información extraída. Para este trabajo se proponen las siguientes aplicaciones, así como áreas de oportunidad para trabajos futuros.

5.1 Aportaciones

A continuación, se consideran las siguientes aportaciones de este trabajo, en base a las cuales se discutirán aplicaciones potenciales, que pueden aportar beneficios a usuarios finales.

5.1.1 Estrategia genérica de extracción de datos

Ya existen trabajos con propuesta de soluciones para la obtención de datos de documentos semi-estructurados; no obstante, la dirección enfocada de estos trabajos no suele ser la misma. Unos se encuentran orientados a la utilización de aproximaciones matemáticas para la detección y extracción de datos; otros, como el modelo ANDES [18], manejan una serie de transformaciones de elementos XML por medio de documentos XSL.

La aportación de nuestra estrategia, es tomar conceptos de varios trabajos previos orientados a la extracción de datos semi-estructurados para que, sin importar el área de interes de la fuente de datos y de la estructura de búsqueda, aplicar la serie de pasos para extraer datos de documentos semi-estructurados que cumplan los requerimientos de una estructura de búsqueda para su futura explotación y/o manipulación.

Como se ve en el caso práctico 1, una misma estructura de búsqueda, se utilizó para extraer información de dos fuentes de datos diferentes.

70

Hay que mencionar, que la misma estructura de búsqueda puede reutilizarse en más de una fuente de datos, siempre y cuando cada una de las fuentes de datos trate de la misma área de interés. En este caso, las modificaciones en la estructura de búsqueda van orientadas hacia la adición y/o corrección de los sinónimos para cada dato.

No obstante, si las fuentes de datos no comparten la misma área de conocimiento, las estructuras de búsqueda van a cambiar en la definición de sus elementos. Para muestra, ambos casos prácticos, donde el área de conocimiento del primero es béisbol, mientras en el segundo es el clima de áreas urbanas. Dada la diferencia en las áreas de conocimiento, las estructuras van a ser distintas, como se puede apreciar en el apéndice al final de este documento.

5.1.2 Reducción en tiempo de alimentación de base de datos

El elemento final de la estrategia es el almacenamiento de información en una base de datos. Se considera que sea una base de datos, porque pueden almacenarse distintas estructuras de información, como en el caso práctico 1, donde se alimentan cuatro diferentes tablas, de acuerdo a la información existente en la “Enciclopedia del Béisbol Mexicano”.

El propósito de dicho almacenamiento es el procesamiento futuro de esta información, donde este procesamiento puede tener una o varias aplicaciones:

1) Realizar minados de datos para descubrir patrones y/o predecir tendencias de información de acuerdo al tiempo.

2) Almacenar información histórica de acuerdo a ciertos elementos de una fuente de datos original, sin considerar todos los elementos mostrados en dicha fuente.

3) Unificación de fuentes de datos, referentes a una misma área de conocimiento, donde no se tiene acceso (o no existe siquiera) a una base de datos de la cual las fuentes de datos obtienen esta información.

71

En la sección 5.3 se comentan aplicaciones donde se ve la utilización de la información generada en esta base de datos.

5.1.3 Seguimiento en el tiempo de una fuente de datos

En algunas ocasiones se puede pensar en monitorear una determinada fuente de datos, de la cual se sabe, cambia su información con una periodicidad definida, sin embargo no se considera necesario recibir un aviso de cuando ocurrió dicho cambio, a diferencia de lo sucedido con una aplicación de RSS [17], donde el objetivo es notificar a un usuario de software de seguimiento RSS de los cambios acontecidos en un sitio determinado.

En este caso, el objetivo es acumular información en el tiempo para poder realizar después explotaciones sobre la misma, en la sección 5.3 se comentan aplicaciones donde se ve la utilización de la información obtenida en el tiempo de esta fuente de datos.

5.2 Trabajos Futuros

Las siguientes secciones se manejarán las áreas de oportunidad que se consideran, pueden mejorar este trabajo propuesto.

5.2.1 Manejo de elementos desconocidos

Existe la probabilidad, de que en una fuente de datos exista más información de la contemplada en la estructura de búsqueda; si bien, en el estado actual del trabajo, no se obtendría información para estos elementos dado que la herramienta de transformación no los tomaría en cuenta para su procesamiento, se puede considerar la necesidad de almacenar esos datos, sin importar si tienen significado o no, ya que en un futuro se le puede proporcionar a la estructura de búsqueda.

Este ejemplo se puede ver en la figura 4.4, mostrada en el caso práctico 2 (sección 4.2) donde además de los datos de temperatura, viento y humedad, se manejan otros tres datos: “Sunrise”, “Sunset” y “Barometic Pressure” no contemplados en la estructura de búsqueda.

72

Para el caso práctico no se almacena esa información en la base de datos, pero pudiere ser necesario hacerlo en el futuro. Si bien, como está actualmente definida la estrategia, pudiere representarse basándose en el concepto del trabajo “Estrategia Dividir y Vencer” para en el caso en que existan más elementos de manera similar a los ya almacenados, se agreguen como elementos de tipo “desconocido”.

Un área de oportunidad es realizar un trabajo para incorporar el manejo de elementos desconocidos, o no previstos, de una forma más natural. Se pueden considerar una, o más, de las siguientes aproximaciones:

1) Cada elemento encontrado como desconocido se agregue al final del documento XML con los datos extraídos, donde el nombre del elemento es “desconocido”, y lo que se considere el valor, aparezca como valor del elemento.

2) En la estructura de búsqueda definir al final, un elemento “desconocido”, al mismo nivel del elemento “dato”, con atributos (o elementos) similares al del elemento “dato” que definan el manejo de este tipo de ocurrencias en la fuente de datos. Esta definición puede incluir que el elemento cumpla con una expresión regular determinada, o pertenezca a algún tipo de dato, o restricciones similares.

No se recomienda, almacenar los valores desconocidos en otra estructura separada de la que contendrá los datos extraídos. Dado que si bien estos elementos pueden aparecer como desconocidos, o no contemplados, en caso de que tengan un significado, este puede ir en contexto con el resto de la información extraída.

5.2.2 Minado por seguimiento de páginas

La facilidad del lenguaje HTML para definir ligas hacia páginas diferentes, para poder agrupar la información en distintas fuentes, conlleva a que no necesariamente toda la información definida en la estructura de búsqueda se encuentre en un solo documento, sino que éste documento tenga solo una parte, mientras que el resto de los elementos que satisfacen la estructura se encuentren en otros documentos.

73

Por ejemplo, supongamos que en el caso de ver datos de una carrera de informática en la página de una universidad mexicana tuviera ligas porque algunas materias se imparten a distancia en una universidad española, es muy probable que la información de las materias impartidas en España, esté en las páginas pertenecientes al servidor de la universidad española.

De igual forma, así como en este trabajo se probó la estrategia llenando una base de datos con la Enciclopedia del Beisbol Mexicano, es posible que aun existan documentos de este tipo que no estén (o al menos de manera pública) almacenados en una base de datos central, y al mismo tiempo se encuentre dispersa esa información entre varias fuentes, donde quizás éstas no esten ni siquiera en formato digital. Convirtiendo a formato digital dichas fuentes es posible incluso preservarlas para un futuro. Sin embargo, es posible que la conversión a formato digital, se de repartida en varios documentos, por lo que se considera como un área de oportunidad.

5.2.3 Interacción con sistemas expertos

Otra área de oportunidad para trabajo futuro para nuestra estrategia es la forma de incluir validaciones de los datos extraidos, de forma que tengan valores permitidos y/o plausibles de acuerdo al dominio de datos de la estructura de búsqueda creada.

Tomando el ejemplo de la estructura de datos que almacena los datos del clima en una determinada región del mundo, uno de los datos que contiene esta estructura es la temperatura, pero existen por lo menos, dos sistemas de medición de temperatura en uso: Fahrenheit y Celsius (o Centígrados). Si bien ambos sistemas utilizan números, la misma cantidad numérica válida en un sistema, puede considerarse como una aberración en el otro. En el caso práctico expuesto en la sección 4.2 aparecen ambos valores, pero suponiendo un caso donde solo existe el valor de un sistema de medición, es factible que la aplicación requiriera el valor en otro sistema, diferente al extraído. En ese caso, el apoyo de un sistema experto, puede ayudar a evaluar el valor extraído y ver si es válido para la aplicación futura.

En este punto es donde entra la interacción con sistemas expertos. Un

74

sistema experto, puede determinar si un valor es permitido dentro de un determinado dominio de datos. Al ver la posibilidad de integrar la extracción de datos de documentos semi-estructurados y evaluar esos datos con un sistema experto, sería posible determinar si los valores son adecuados o no, sin necesidad de encontrar errores al momento de utilizar una aplicación con los datos extraidos, como el grabar esa información en una base de datos, que tenga validaciones y requerimientos definidos por tabla.

Esto también abarca el siguiente escenario: ¿qué sucede si la fuente tiene datos erróneos en primer lugar? De acuerdo a como está definida la estrategia para extraer información, no habría forma de detectar errores, o datos no considerados, sino hasta el momento de usar una aplicación sobre los datos. Un ejemplo se ve en el caso de los campos de la Enciclopedia del Beisbol Mexicano, que se detectaron algunos errores existentes en el documento, como jugadores que tienen valores inalcanzables en campos, de acuerdo al dominio de datos, como un porcentaje de bateo superior a 1.000, lo cual por definición no puede darse. O jugadores, que aparecen con estadísticas deportivas, pero no con equipo.

5.2.4 Disminución de intervención humana en el proceso

Una meta de la extracción de datos de documentos semi-estructurados, es reducir la intervención de un operador humano en el proceso. Sin embargo, se considera, al menos en esta etapa del diseño de la estrategia, que no es posible erradicarla por completo. Esto es considerando el principio de incertidumbre mencionado en [12] y aduciendo los siguientes factores:

1) Adecuación de la estrucutra de búsqueda. Suponiendo cambios en las fuentes, o la adición de nuevas fuentes. La estructura inicial de búsqueda necesita poder procesar esos cambios para generar las estructuras de extracción. También es necesaria la revisión humana de estos documentos, al menos la primera vez que se generaron, para comprobar que están extrayendo los datos correctos.

75

2) Es necesario evalúar los datos obtenidos, por lo menos después de la primera extracción. Es posible que las estructuras de extracción regresen valores válidos, desde el punto de vista sintáctico. Mas no necesariamente, desde un punto de vista semántico, pues pueden existir valores en la fuente que estén incorrectos, o estén posicionados de manera errónea en el documento.

3) Otra razón para evaluar los datos, es que los datos pueden ser correctos tanto sintáctica, como semánticamente, pero ¿qué garantía tenemos que son los datos correctos? O si la extracción de datos se da sobre diferentes fuentes, ¿existe consistencia entre dos representaciones de la información sobre un mismo objeto?. ¿Dos representaciones diferentes de la misma información, es necesariamente una inconsistencia? Por ejemplo, la fecha de nacimiento de una persona, desplegada en una página orientada hacia México y la otra hacia Estados Unidos de Norteamérica. En México se acostumbra representar las fechas indicando primero el día, luego el mes y al final el año; mientras que en Estados Unidos de Norteamérica, se acostumbra primero indicar el mes, luego el día y después el año. Una persona que nació el 13 de septiembre, en el sistema mexicano se despliega como 13-9, lo cual, si se traslada literalmente al sistema estadounidense es una inconsistencia, pues no existe mes 13; pero en el sistema estadounidense se representa como 9-13, lo que demuestra que aunque sintácticamente son diferentes, semánticamente representan el mismo valor y no es una inconsistencia.

Se considera como área de trabajo futuro, el ver la posibilidad de reducir dicha interacción, mas no erradicarla por completo, porque se considera virtualmente imposible. Una recomendación es la interacción con sistemas expertos para validar la información, como es sugerido en la sección anterior de este capítulo.

5.2.5 Agentes Inteligentes

Se considera la interacción en la creación y operación de agentes inteligentes como otra área de oportunidad de este trabajo. Un agente inteligente es un sistema situado dentro de un ambiente, donde lo monitorea y es capaz de adaptarse con el tiempo a cambios de dicho

76

ambiente [19]. Las aplicaciones de dichos agentes varían, siendo la más frecuente, el monitoreo de un sitio de internet definido, para reportar cambios.

Dado que una de las aplicaciones sugeridas para la estrategia de extracción propuesta en este documento, es precisamente el monitoreo de datos, se piensa que esta estrategia de extracción sería un buen complemento para el diseño de agentes, sobre todo pensado por el concepto manejado de definición de sinónimos. Ya que un agente inteligente se define para trabajar de acuerdo a un dominio de datos, de igual forma, la estructura de búsqueda de datos en esta estrategia de extracción, se encuentra también definida para un dominio de datos determinado. En este aspecto, se considera que el concepto de agregar sinónimos a la estructura de búsqueda, sería de gran utilidad para la creación y actualización de agentes inteligentes.

5.3 Aplicaciones

En esta sección se proponen aplicaciones para la estrategia mencionada en este documento. En todos los casos la aplicación sugerida requiere acceso a la fuente de datos como un documento HTML.

5.3.1 Extracción de datos específicos de monitoreo de bases de datos

Existen aplicaciones que monitorean el desempeño y estatus de una (o varias) bases de datos. Un ejemplo es la herramienta Patrol Enterprise Manager [20]. Esta herramienta genera reportes en formato HTML, donde se despliega información de 230 parámetros referentes al desempeño y disponibilidad de una base de datos.

En un determinado ambiente, se puede solicitar información referente solo a ciertos parámetros, como por ejemplo: espacio libre para datos, espacio libre en el disco de almacenamiento, cantidad de “locks” entre tablas y cantidad de sesiones a la base de datos.

La utilidad propuesta en este caso es realizar la extracción de los

77

parámetros indicados en el ejemplo, con el fin de almacenar esa información histórica para determinar tendencias como:

1) Tiempo transcurrido en que es necesario crecer ya sea el espacio libre para datos, o sobre el disco de almacenamiento. Para este caso se asume que no se puede depurar información de la base de datos, pues es requisito conservar información histórica.

2) Época en que hay una mayor cantidad de accesos, para solicitar mayor poder de cómputo en caso de que la base se encuentra en un arreglo de máquinas que permiten la adición y/o eliminación de recursos con facilidad.

3) Época en que existe una mayor cantidad de “locks” por accesos simultáneos a tablas. Este parámetro pudiere tiene relación con la cantidad de accesos a la base de datos, pero no necesariamente, de ahí la necesidad de determinar si existe una tendencia para prevenir el problema.

Estas tendencias pueden usarse para justificar, primordialmente, la compra y/o mejora de equipo existente. O incluso, el justificar una mayor revisión de la aplicación, sin necesidad de adquirir equipo de computo nuevo o de mayor capacidad.

5.3.2 Aplicaciones de seguimiento de datos.

Generalmente, un seguimiento de datos de una determinada fuente de datos, involucra el monitoreo de la información presentada en la misma. Si la fuente de datos es una página Web de un determinado sitio, se proponen las siguientes aplicaciones:

1) Monitoreo de precios de productos similares a los producidos por una organización en un mercado abierto. Ya que en un mercado abierto, se puede publicar la divulgación de precios y productos por medio de páginas Web, donde tanto la organización en cuestión, como sus competidores, publiciten sus productos de esta forma. Es probable que esta práctica ya se haga, pero quizás de forma artesanal, sin involucrar algún algoritmo o programa de búsqueda. Un ejemplo son productos de supermercados.

78

2) Monitoreo por un usuario de precio y disponibilidad de un determinado producto o servicio, que tenga interés por adquirir. En este caso, el objetivo es determinar la mejor fecha para la compra de dicho producto o servicio considerando un mejor precio, mayor disponibilidad o estabilidad de un determinado proveedor. Por ejemplo, un boleto de viaje.

5.4 Conclusiones

Se puede considerar la situación de la validación de la información extraída, como el área de mayor trabajo futuro. La disminución de la necesidad de intervención de un operador humano, para validar la información obtenida, va a ser un avance valioso para esta estrategia. Esto es debido a que el tiempo de alimentación inicial de la base de datos, que fungirá como repositorio de la información extraída, se incrementa debido a la necesidad de evaluar los datos obtenidos durante las primeras extracciones. También aplica la situación, si el usuario percibe un cambio en la cantidad de datos mostrados por los documentos que sirven como fuente de datos, y debe adaptar la estructura de búsqueda XML para lidiar con los nuevos elementos.

En este trabajo, considerando el desempeño en los casos prácticos, hemos concluido que la estrategia de extracción de datos propuesta puede tener aplicaciones para alimentación masiva de bases de datos, o monitoreo de fuentes de datos. En ambos casos, con fines de realizar explotaciones posteriores a los datos guardados en dicha base de datos.

79

Capítulo 6. Conclusiones del trabajo

Este trabajo aporta una aproximación flexible para permitir extraer información referente a un dominio de datos, pero de fuentes diferentes, aun cuando dichas fuentes tengan distintas formas de almacenar y/o desplegar dicha información, minimizando (más no erradicando) el involucramiento de un operador humano para validar la información o realizar ajustes para la extracción de la misma, como se vió en los casos prácticos mostrados en el capítulo 4.

El diseño original de la estructura de datos XML a buscar influye de manera significativa en el desempeño de la extracción de datos. Se recomienda consultar más de una fuente de datos, para diseñar el modelo de la estructura de búsqueda. Para este fin, se recomienda consultar las fuentes definitivas de consulta, o en su defecto, fuentes de datos representativas que contengan todos los datos a buscar. De esta forma la estructura de búsqueda podrá ser útil para generar documentos de extracción XSL útiles para cada una de las fuentes.

Es importante recalcar que el diseñador de la estructura de búsqueda debe tener amplios conocimientos sobre el área de conocimiento de la información a buscar. Retomando el primer caso práctico, el hecho de conocer la terminología de béisbol en ambos idiomas fue crucial, puesto que se pudieron renombrar los elementos de la estructura de búsqueda para evitar colisiones entre valores de datos y sinóminos de otros datos. Sin embargo en el segundo caso práctico se vió una notable dificultad para agregar sinónimos, e incluso elementos, debido a la practicamente nula familiaridad con el dominio de datos, notando la dificultad al manejar los dos sistemas de medición en los que se reporta la temperatura de una ciudad. Este amplio conocimiento del área de conocimiento permite crear validaciones de nivel sintáctico, que cheque la validez de los datos extraídos desde el punto de vista sintáctico. Como ya se mencionó en la sección 5.2.3, se recomienda como un área de trabajo futuro, la aplicación de validaciones semánticas ya sea durante el proceso de extracción, o una vez terminado éste y previo al almacenamiento en la base de datos.

Asumiendo el caso de que el destino final de la extracción de datos sea alimentar una base de datos, no es necesario diseñar una estructura

80

de búsqueda XML por cada tabla de la misma. Un documento XML permite suficiente flexibilidad para poder utilizarse en más de una base de datos y/o aplicación, facilitando su transportabilidad hacia otros sistemas. Tomando como ejemplo el caso práctico de los datos de la Enciclopedia del Béisbol Mexicano, hay más de una tabla para guardar toda la información de jugadores.

El documento de extracción de datos XSL cumple la función de obtener información de un documento que poseé una estructura determinada, sin embargo, una variación en la estructura del documento fuente puede generar extracciones equivocadas, o en el peor caso, que el documento de extracción sea completamente inutil. Por ello es importante desde la definición de la estructura de búsqueda, que es la que generará el documento de extracción XSL, considerar los sinonimos que puede tener cada elemento.

81

REFERENCIAS BIBLIOGRÁFICAS

[1] MYLLYMAKI, JUSSI. Web Based DataMining. IBM, Junio 2001. http://www-106.ibm.com/developerworks/web/library/wa-wbdm

[2] EXTENSIBLE MARKUP LANGUAGE (XML).http://www.w3c.org/XML/

[3] THE EXTENSIBLE STYLESHEET LANGUAGE FAMILY (XSL)http://www.w3.org/Style/XSL/

[4] BERTINO, E. & FERRARI, E. XML and data integration. Internet Computing, IEEE , Volume 5, Issue 6, páginas 75-76. Nov/Dec 2001.

[5] XHTML™ 1.0 THE EXTENSIBLE HYPERTEXT MARKUP LANGUAGE http://www.w3.org/TR/2000/REC-xhtml1-20000126/

[6] CHAWATE, SUDARSHAN S., ABITEBOUL, S. & WINDOM, JENNIFER. Representing and querying changes in semistructured data.Proceedings of 14th International Conference on Data Engineering.Orlando, Fl, USA. 1998.

[7] BADR, Y., SAYAH, M., LAFOREST, F. & FLORY, A.Transformation rules from semi-structured XML documents to database model. Computer Systems and Applications, ACS/IEEE International Conference on. Páginas 181-184. 2001.

[8] OUAHID, H. & KARMOUCH, A. Converting Web pages into well-formed XML documents. International Conference on Communications ICC '99 IEEE. Volume 1, páginas 676-680. 1999.

[9] ZHOA LI & WEE KEONG NG. WICCAP: from semi-structured data to structured data. 11th. IEEE International Conference and Workshop on the Engineering of Computer-Based Systems Proceedings. Páginas 86-93. 24-27 May 2004.

[10] ARASU, A. & GARCIA-MOLINA, H. Extracting Structured Data from Web Pages. IBM Systems Journal. Armonk. 2003.

82

[11] FLESCA, S., MANCO, G., MASCIARI, E., PONTIERI, L. & PUGLIESE, A. Fast detection of XML structural similarity. IEEE Transactions on knowledge and Data Engineering. Vol. 17. Issue 2. Páginas. 160-175. Febrero 2005.

[12] HUNG, E., GETOOR, L. & SUBRAHMANIAN, V.S. PXML: a probabilistic semistructured data model and algebra. 19th

International Conference on Data Engineering, 2003. Proceedings. Páginas 467-478. 5-8 Marzo 2003.

[13] ZHOU FENG, WYNNE HSU & MONG LI LEE. Efficient Pattern Discovery for Semistructured Data. 17th. IEEE International Conference on tools with Artificial Intelligence, 2005 ICTAI 05. Páginas 294-301. 14-16 Nov. 2005

[14] COMBI, C.; OLIBONI, B.; ROSSATO, R. Querying XML documents by using association rules. 16th. International Workshop on Database and Expert Systems Applications, 2005. Proceedings. Páginas 1020-1034. 22-26 Aug. 2005.

[15] SCHMIDT, A. KERSTEN, M. WINDHOUWER, M. Querying XML documents made easy: nearest concept queries. International Conference on Extending Database Technology (EDBT). CWI. Amsterdam. 2001.

[16] JI ZHANG, HAN LIU, TOK WANG LING, ROBERT M. BRUCKNER, & A MIN TJOA. A Framework for Efficient Association Rule Mining in XML Data. Journal of Database Management. Vol. 17, Issue 3, páginas 19, 22. Jul-Sep 2006.

[17] REALLY SIMPLE SYNDICATIONhttp://www.rssboard.org/rss-specification

[18] MYLLYMAKI, JUSSI. Effective Web Data Extraction with Standard XML Technologies. WWW10, May 2-5, 2001.http://www10.org/cdrom/papers/102

[19] PETRIE, CHARLES J. Agent-Based Engineering, the Web, and Intelligence. IEEE Expert. Diciembre 1996

83

[20] BMC Patrol Enterprise Managerhttp://www.bmc.com/products/proddocview/0,2832,19052_0_23191_7266,00.html

84

Apéndice: Estructuras XML de datos de beisbol.

Datos de bateador

<Jugador><Nombre /><Lado de bateo /><Tira /><Fecha de nacimiento /><Lugar de nacimiento /><Posición /><Datos>

<Año /><Equipo /><PCT /><Juegos /><Veces al bat /><Carreras Anotadas /><Hits /><Total de bases /><Dobles /><Triples /><Homeruns /><Carreras Producidas /><Sacrificios /><Elevados de Sacrificio /><Golpeado /><Bases por bola /><Bases intencionales /><Ponches /><Bases Robadas /><Intentos de robo /><Bateo para Doble play /><Slugging />

</Datos></Jugador>

85

Búsqueda de información de bateadores.

<dato> Jugador </dato><dato @multiple=”no”> Nombre </dato><dato @multiple=”no”> Lado de bateo

<sinonimo> B: </sinonimo></dato><dato @multiple=”no”> Tira

<sinonimo> T: </sinonimo></dato><dato @multiple=”no”> Fecha de nacimiento

<sinonimo> Nació/Born: </sinonimo></dato><dato @multiple=”no”> Lugar de nacimiento

<sinonimo> En/in: </sinonimo></dato><dato @multiple=”no”> Posición

<sinonimo> P: </sinonimo></dato><dato> Año <sinonimo> Year </sinonimo> </dato><dato> Equipo <sinonimo> Team </sinonimo> </dato><dato> PCT <sinonimo> BA </sinonimo> </dato><dato> Juegos <sinonimo> J </sinonimo> <sinonimo> G </sinonimo> </dato><dato> Veces al bat <sinonimo> V </sinonimo> <sinonimo> AB </sinonimo> </dato><dato> Carreras <sinonimo> C </sinonimo> <sinonimo> R </sinonimo> </dato><dato> Hits <sinonimo> H </sinonimo> </dato><dato> Total de Hits <sinonimo> TBH </sinonimo> <sinonimo> TB </sinonimo> </dato><dato> Dobles <sinonimo> H2 </sinonimo> <sinonimo> 2B </sinonimo> </dato><dato> Triples <sinonimo> H3 </sinonimo> <sinonimo> 3B </sinonimo> </dato><dato> Homeruns <sinonimo> HR </sinonimo> </dato><dato> Carreras Producidas

<sinonimo> CP </sinonimo> <sinonimo> RBI </sinonimo>

</dato><dato> Sacrificios <sinonimo> SH </sinonimo> </dato>

86

<dato> Elevados de Sacrificio <sinonimo> SF </sinonimo> </dato><dato> Golpeado <sinonimo> PP </sinonimo> <sinonimo> HBP </sinonimo> </dato><dato> Bases por bola <sinonimo> BB </sinonimo> </dato><dato> Bases Intencionales

<sinonimo> BI </sinonimo> <sinonimo> IBB </sinonimo>

</dato><dato> Ponches <sinonimo> SO </sinonimo> </dato><dato> Bases Robadas

<sinonimo> BR </sinonimo> <sinonimo> SB </sinonimo>

</dato><dato> Intentos de Robo

<sinonimo> AR </sinonimo> <sinonimo> CS </sinonimo>

</dato><dato> Bateo para Doble Play

<sinonimo> RDP </sinonimo> <sinonimo> GDP </sinonimo>

</dato><dato> Slugging <sinonimo> SLG </sinonimo> </dato>

87

Datos de lanzadores

<Jugador><Nombre /><Tira /><Fecha de nacimiento /><Lugar de nacimiento /><Posición /><Datos>

<Año /><Equipo /><Ganados /><Perdidos /><PCT /><PCLA /><Juegos /><Juegos Iniciados /><Juegos Completos /><Cierre de Juegos /><Juegos Salvados /><Innings Lanzados /><Hits admitidos /><Carreras admitidas /><Carreras limpias /><Homerunes admitidos /><Sacrificios /><Elevados de sacrificio /><Pelotazos /><Bases por bolas /><Bases intencionales /><Ponches /><Wild Pinches />

</Datos></Jugador>

88

Búsqueda de información de lanzadores.

<dato> Jugador </dato><dato @multiple=”no”> Nombre </dato><dato @multiple=”no”> Tira

<sinonimo> T: </sinonimo></dato><dato @multiple=”no”> Fecha de nacimiento

<sinonimo> Nació/Born: </sinonimo></dato><dato @multiple=”no”> Lugar de nacimiento

<sinonimo> En/in: </sinonimo></dato><dato> Año <sinonimo> Year </sinonimo> </dato><dato> Equipo <sinonimo> Team </sinonimo> </dato><dato> Ganados <sinonimo> G </sinonimo> <sinonimo> W </sinonimo> </dato><dato> Perdidos <sinonimo> P </sinonimo> <sinonimo> L </sinonimo> </dato><dato> PCT </dato><dato> PCLA <sinonimo> ERA </sinonimo> </dato><dato> Juegos <sinonimo> J </sinonimo> </dato><dato> Juegos Iniciados

<sinonimo> JI </sinonimo> <sinonimo> GS </sinonimo>

</dato><dato> Juegos Completos

<sinonimo> JC </sinonimo> <sinonimo> CG </sinonimo>

</dato><dato> Cierre de juegos

<sinonimo> CJ </sinonimo> <sinonimo> ShO </sinonimo>

</dato><dato> Juegos Salvados

<sinonimo> JS </sinonimo> <sinonimo> SV </sinonimo>

</dato><dato> Innings Lanzados <sinonimo> IP </sinonimo> </dato><dato> Hits Admitidos <sinonimo> HA </sinonimo> </dato>

89

<dato> Hits <sinonimo> H </sinonimo> </dato><dato> Carreras Admitidas

<sinonimo> CA </sinonimo> <sinonimo> R </sinonimo>

</dato><dato> Carreras Limpias

<sinonimo> CL </sinonimo> <sinonimo> ER </sinonimo>

</dato><dato> Homeruns Admitidos <sinonimo> HR </sinonimo> </dato><dato> Sacrificios <sinonimo> SH </sinonimo> </dato><dato> Elevados de Sacrificio <sinonimo> SF </sinonimo> </dato><dato> Pelotazos <sinonimo> PP </sinonimo> <sinonimo> HBP </sinonimo> </dato><dato> Bases por bola

<sinonimo> BB </sinonimo> <sinonimo> IBB </sinonimo>

</dato><dato> Bases Intencionales <sinonimo> BI </sinonimo> </dato><dato> Ponches <sinonimo> SO </sinonimo> </dato><dato> Wild Pitches <sinonimo> WP </sinonimo> </dato>

Búsqueda de información de temperatura

<dato> Temperatura<dominio> [0-9]*&deg; </dominio><sinonimo> Temperature </sinonimo>

</dato><dato @multiple=”no”> Humedad

<sinonimo> Humidity </sinonimo></dato><dato @multiple=”no”> Viento

<sinonimo> Wind </sinonimo></dato>

90