Approach to validation

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}

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:

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:

<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

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.

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.

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.