Knowledge-based engineering (KBE) approach

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>.

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>

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

Monterrey 3-1 Tigres Veracruz 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 “Captura semi-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].

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.