DENODO ITPILOT 4.0 MANUAL DEXTLhelp.denodo.com/platform-docs/4.0/DenodoITPilot.ManualDEXTL.pdf ·...

DENODO ITPILOT 4.0 MANUAL DEXTL

NOTA Este documento es confidencial y propiedad de denodo technologies (en adelante denodo). Ninguna de las partes del documento puede ser copiada, fotografiada, fotocopiada, transmitida electrónicamente, almacenada en un sistema de gestión documental o reproducida mediante cualquier otro mecanismo sin la autorización previa o por escrito de denodo.

copyright © 2007 Queda prohibida la reproducción total o parcial de este documento sin la autorización por escrito de denodo technologies

ITPilot 4.0 Manual DEXTL

ÍNDICE

PREFACIO........................................................................................................................................................................... I ALCANCE ..................................................................................................................................................................... I QUIÉN DEBERÍA USAR ESTE MANUAL ................................................................................................................. I RESUMEN DE CONTENIDOS.................................................................................................................................... I

1 INTRODUCCIÓN ..................................................................................................................................... 1

2 DEXTL A VISTA DE PÁJARO ................................................................................................................ 2

3 SINTAXIS BÁSICA ................................................................................................................................. 5 3.1 FUNDAMENTOS DE ESPECIFICACIÓN DE PATRONES ................................................................... 5 3.2 AMBIGÜEDAD DE PATRONES Y DELIMITACIÓN DEL ESPACIO DE BÚSQUEDA..................... 10 3.3 RELACIONES Y SUBRELACIONES..................................................................................................... 13

3.3.1 Subrelaciones.......................................................................................................................................... 13

4 SINTAXIS AVANZADA ........................................................................................................................ 17 4.1 ATRIBUTOS CON VALOR FIJO Y CON VALOR POR DEFECTO ...................................................... 17 4.2 SEPARADORES VORACES.................................................................................................................. 18 4.3 DEFINICIÓN DE MARCAS DE FORMATO ......................................................................................... 18

4.3.1 Juegos de Marcas................................................................................................................................... 21 4.4 JERARQUÍA DE ELEMENTOS............................................................................................................. 22 4.5 ESPECIFICACIONES ALTERNATIVAS............................................................................................... 23 4.6 ESCÁNERS ............................................................................................................................................ 24 4.7 GENERACIÓN E INSTALACIÓN DE NUEVOS ESCANERS ............................................................. 24 4.8 ESTRUCTURA DE UN PROGRAMA DEXTL....................................................................................... 26

4.8.1 Sección de Declaraciones....................................................................................................................... 26 4.8.2 Sección de Especificación....................................................................................................................... 27

4.9 ESCAPADO DE CARACTERES EN DEXTL ......................................................................................... 27

5 ANEXO A: FUNCIONALIDAD DEXTL OBSOLETA ............................................................................ 29 5.1 PATRÓN TO CON DESCARTE DE INFORMACIÓN .......................................................................... 29 5.2 CONTEXTOS PARA ATRIBUTOS........................................................................................................ 29 5.3 JERARQUÍA DE ELEMENTOS AUXILIARES ..................................................................................... 30 5.4 ACCIONES ............................................................................................................................................. 30

5.4.1 Acciones existentes ................................................................................................................................ 31 5.4.2 Acciones de Navegación (GOROUTE, ADDROUTE, RETURNROUTE)...................................................... 34

5.5 CONTEXTOS DE NAVEGACIÓN ......................................................................................................... 35

BIBLIOGRAFÍA ............................................................................................................................................................... 37


ÍNDICE DE FIGURAS Figura 1 Resultados de búsqueda de una tienda electrónica de música ............................................................... 3 Figura 2 Código HTML asociado a la Figura 1 ........................................................................................................ 4 Figura 3 Programa DEXTL de extracción de datos de la tienda de música ............................................................ 4 Figura 4 Fragmento HTML con Datos sobre un Libro. ............................................................................................ 7 Figura 5 Definición de EOL...................................................................................................................................... 7 Figura 6 Definición de un Patrón Sencillo............................................................................................................... 7 Figura 7 Resultado de búsqueda de librería electrónica ........................................................................................ 8 Figura 8 Código HTML de resultado de búsqueda de librería electrónica ............................................................. 9 Figura 9 patrón DEXTL de obtención de elementos de librería electrónica ........................................................... 9 Figura 10 Resultados Tabulados de una Tienda de Libros ..................................................................................... 10 Figura 11 Patrón Ambiguo....................................................................................................................................... 11 Figura 12 Uso de FROM y END_FROM ................................................................................................................... 11 Figura 13 Solución del Problema de Ambigüedad.................................................................................................. 12 Figura 14 Aplicación de un Patrón a Dos Zonas ..................................................................................................... 12 Figura 15 Utilización del patrón FROM para obtención de información adicional ................................................. 13 Figura 16 Salida de una Tienda Electrónica de Películas....................................................................................... 14 Figura 17 Patrón ...................................................................................................................................................... 15 Figura 18 HTML de la Figura 16 sin las Etiquetas irrelevantes.............................................................................. 15 Figura 19 Patrón ...................................................................................................................................................... 17 Figura 20 Presentación de Resultados en una Fuente Web................................................................................... 18 Figura 21 Especificación Errónea............................................................................................................................ 18 Figura 22 Especificación correcta con separadores voraces................................................................................. 18 Figura 23 Patrón que Extrae Información de una Marca de Formato..................................................................... 20 Figura 24 Juego de Marcas .................................................................................................................................... 21 Figura 25 Especificaciones Alternativas................................................................................................................. 23 Figura 26 Juego de Marcas STANDARD ................................................................................................................ 25 Figura 27 Juego de Marcas COMENTARIO ............................................................................................................ 25 Figura 28 Escáner con Juegos de Marcas STANDARD y COMENTARIO............................................................... 25 Figura 29 Sintaxis para una Acción ........................................................................................................................ 31 Figura 30 Patrón ...................................................................................................................................................... 36


Prefacio i

PREFACIO

ALCANCE

Este manual describe de manera detallada el lenguaje de especificación de patrones, DEXTL, utilizado en Denodo ITPilot.

QUIÉN DEBERÍA USAR ESTE MANUAL

Este manual está destinado a integradores, jefes de proyecto y en general todo profesional que necesite consultar las posibilidades que ofrece Denodo ITPilot o utilizar el mismo para extraer información de fuentes web. Este manual asume conocimientos básicos de:

• HTML.

RESUMEN DE CONTENIDOS

Capítulo 1: Introducción a la problemática de extracción de información de fuentes de información semiestructurada y presentación de la estructura de DEXTL, el lenguaje de especificación de patrones. Capítulo 2: Describe y define la sintaxis básica del lenguaje de especificación de procesamiento de lenguaje, DEXTL. El capítulo se complementa con ejemplos prácticos de uso. Capítulo 3: Se presentan características avanzadas de la sintaxis de DEXTL.


Introducción 1

1 INTRODUCCIÓN

La mayor parte de la información que se obtiene de fuentes WWW (Worldwide Web) se expone utilizando el lenguaje de etiquetas HTML, centrado en la visualización de datos por parte de seres humanos. Sin embargo, el crecimiento constante de la web hace imposible acceder a sus datos si no es de manera mecánica. Muchas de las fuentes web generan sus registros también de forma automática –con repositorios de datos cuyo acceso se realiza a través de frontales HTML-. Este documento introduce el lenguaje DEXTL (Data Extraction Language, Lenguaje de Extracción de Datos), que permite obtener una visión estructurada de la información contenida en páginas HTML obtenidas previamente (probablemente mediante el lenguaje NSEQL, del cuál se puede obtener más información en [NSEQL]). Debe recordarse que normalmente no es necesario crear manualmente programas DEXTL. El entorno gráfico de generación de ITPilot [GENER] permite crear gráficamente mediante ejemplos los programas DEXTL necesarios para la extracción de datos de la gran mayoría de sitios web. De todas formas, este manual proporciona una descripción exhaustiva del lenguaje para usuarios avanzados.


DEXTL a Vista de Pájaro 2

2 DEXTL A VISTA DE PÁJARO

Un programa DEXTL se compone de elementos estructurados de manera jerárquica; estos elementos reflejan los ítems de información que se desean extraer de un documento o conjunto de documentos. Por ejemplo, si se quiere obtener una vista estructurada de una lista de mensajes de una fuente de WebMail, tendríamos elementos DEXTL para ítems de información tales como mensajes, asuntos, emisores, receptores, etc. Para entender este proceso, en primer lugar es importante notar que un documento web contiene dos tipos de información que aparecen mezclados en el mismo:

• Información para el usuario: textos visibles para el usuario donde realmente estará la mayor parte de la información a extraer.

• Información para la herramienta visualizadora: marcas HTML con información de formato que indican al navegador como representar gráficamente los textos visibles al usuario.

Los ítems de información que pueden ser extraídos mediante DEXTL son acordes a un esquema de datos jerárquico en el cuál cada item estará compuesto por una serie de atributos que pueden ser atómicos o no atómicos. Un atributo atómico puede tomar como valor una cadena de caracteres, mientras que un atributo no atómico estará a su vez compuesto por una serie de subatributos, atómicos o no. Para comprenderlo adecuadamente, se puede pensar en una aplicación de venta electrónica de música (p.e. CDs, cassettes, etc.) de la cuál se quiere obtener, para cada álbum, información acerca del TÍTULO del álbum, nombre del ARTISTA, FECHA de grabación, e información sobre la EDICIÓN, que es un atributo no atómico compuesto por el FORMATO y el PRECIO del álbum. Típicamente, un programa DEXTL tendrá un elemento no atómico para cada atributo no atómico del esquema de los datos a extraer. Los diferentes elementos de un programa DEXTL estarán relacionados jerárquicamente de la misma forma que los atributos a los que están asociados dentro del esquema de los datos a extraer. Cada elemento no atómico de un programa DEXTL se compone típicamente de uno o más patrones DEXTL. La definición detallada de un patrón DEXTL se verá en los siguientes apartados, pero por ahora basta con saber que un patrón define una secuencia de datos y de separadores entre esos datos que, de alguna manera, reflejan la forma en que están dispuestos en las páginas web objetivo los datos correspondientes al atributo no atómico al que el patrón DEXTL está asociado. La estructura básica de un elemento DEXTL se describe a continuación:

- Nombre del elemento. - Cláusula FROM: identifica el comienzo de la región del documento donde se van a buscar las instancias del

elemento –región de búsqueda-. Si en el programa no aparece esta cláusula, se toma el FROM del elemento padre (es decir, desde el nivel anterior). Si éste no tuviese FROM, o no existiese ese subelemento, se considera el comienzo del documento.

- Cláusula TO: identifica el fin de la región de búsqueda del elemento concreto. Si esta cláusula no aparece en el programa, el final de documento se considera como delimitador de la región de búsqueda.

- Entre ambas cláusulas de delimitación se encuentra el patrón DEXTL de EXTRACCIÓN que describe los subelementos del elemento en cuestión y cómo se encuentran agrupados en la región de búsqueda, permitiendo por tanto su identificación y extracción.



Todas las cláusulas mencionadas están compuestas por patrones DEXTL. Un patrón DEXTL está compuesto de una lista de elementos de texto visible a extraer (a los que llamaremos tokens de texto) que están dispuestos consecutivamente en una página web y que están separados entre sí por separadores. Los tokens de texto representan texto en la página mostrada por el browser. Tienen asociado un nombre (prefijado con el character ‘:’) que típicamente coincide con el nombre de un atributo atómico del elemento de datos al que el patrón está asociado. El nombre reservado IRRELEVANT es utilizado para representar tokens de texto presentes en el patron que no se desea extraer. Los separadores entre tokens pueden ser de dos tipos:

1. Separadores de tipo cadena de caracteres. Representan textos visibles en la página que actúan como separadores entre tokens de texto.

2. Separadores de tipo marca de formato. Representan una expresión regular definida sobre etiquetas HTML. Típicamente son utilizados para especificar de una única forma primitivas básicas de representación que pueden ser expresadas de diferentes formas en HTML. Por ejemplo, podríamos definer un separador EOL como sigue: EOL = ("<br>"| "</p>"| "</tr>" | ”</td>” ([ \n\r\t])* </tr>”).

Aunque pueden definirse nuevos separadores de tipo marca de formato a conveniencia, DEXTL incluye separadores ya creados que son suficientes para la gran mayoría de necesidades. Cada patron DEXTL tiene asociado un conjunto de separadores de tipo marca de formato, que son indicados mediante la construcción TAGSET. Todas las etiquetas HTML que no concuerden con algún separador de tipo marca de formato incluido en el juego en uso para el patrón actual, son ignoradas. Ejemplo: La Figura 1 muestra dos resultados de búsqueda de una tienda electrónica de música.

Figura 1 Resultados de búsqueda de una tienda electrónica de música

Se desea extraer el conjunto de ítems correspondiente al elemento ALBUM:{TÍTULO, ARTISTA, FECHA, EDICIÓN:{FORMATO, PRECIO}}. La Figura 2 muestra el fragmento de código HTML procedente de la figura anterior, pero con la omisión de algunos atributos de etiqueta para mejorar la legibilidad.



Figura 2

Figura 3

<TR> <TD><IMG></TD> <TD>Album title </TD> <TD>Artist </TD> <TD>Date </TD> <TD>Format/price </TD> </TR> <TR> <TD><A><IMG></A></TD> <TD><A>DON’T TURN ME FROM YOUR DOOR</A></TD> <TD><A>JOHN LEE HOOKER</A></TD> <TD>2/1992 </TD> <TD>CD / £9.07<BR>MC / £7.93<BR></TD> </TR> <TR> <TD><IMG></TD> </TR> <TR> <TD><IMG></TD> <TD><A>IN THROUGH THE OUT DOOR</A></TD> <TD><A>LED ZEPPELIN</A></TD> <TD>8/1994</TD> <TD>CD / £11.85<BR>LP / £29.28<BR>MC / £9.59<BR></TD> </TR> <TR> <TD><IMG></TD> </TR>

Código HTML asociado a la Figura 1

La Figura 3 muestra el código del programa DEXTL que es capaz de extraer las ocurrencias de un elemento ALBUM. Posteriormente en este manual se describirá en detalle cada uno de los componentes del programa.

{ NAME="ALBUM" FROM "Album title" TAB "Artist" TAB "Date" TAB "Format/Price" END_FROM ANCHOR :TITULO ENDANCHOR TAB ANCHOR :ARTISTA ENDANCHOR TAB :FECHA { NAME="EDICION" :FORMATO "/ £" :PRECIO } <EOL EOL> }

Programa DEXTL de extracción de datos de la tienda de música


Sintaxis Básica 5

3 SINTAXIS BÁSICA

En esta sección se detalla la sintaxis básica de un programa DEXTL. Se comienzan definiendo los fundamentos básicos para construir patrones DEXTL y, posteriormente, se muestra como utilizarlos en la construcción de programas DEXTL completos.

3.1 FUNDAMENTOS DE ESPECIFICACIÓN DE PATRONES

En primer lugar, debemos presentar la idea de que dentro de un programa DEXTL, el uso más habitual para un patrón DEXTL es dentro de la claúsula de EXTRACCIÓN de un determinado elemento. Tal y como se verá en detalle más adelante y cómo ya se ha comentado, un elemento dentro de un programa DEXTL se corresponde con una relación o con un atributo no atómico de una relación (que puede, por tanto, ser visto como una sub-relación) cuyas t-uplas se quieren extraer a través de dicho elemento del programa DEXTL (por tanto, a lo largo del documento este concepto se nombrará “elemento” o “relación” de manera indistinta). Llamaremos R a la relación o subrelación de cuál deseamos extraer sus t-uplas mediante un elemento de un programa DEXTL. En cuanto a la sintaxis de un elemento dentro de un programa DEXTL, por ahora, basta con tener en cuenta que:

• La especificación de un elemento dentro de un programa DEXTL se delimita mediante el carácter de comienzo ‘{‘ y el carácter de fin ‘}’

• Cada elemento puede tener asociado un nombre, que debe coincidir con el de la relación o el atributo no atómico de la misma cuyas t-uplas extrae y que se indica con la notación ‘NAME=”NOMBRE_ELEMENTO”’, donde NOMBRE_ELEMENTO es el nombre asignado al elemento. Este nombre debe indicarse justo después de la marca de apertura de elemento. Si no se indica, el sistema asignará al elemento un nombre cualquiera.

• Dentro de un programa DEXTL pueden incluirse líneas de comentarios, prefijadas con los símbolos ‘//’.

• Todo elemento contiene dentro de su claúsula de extracción al menos un patrón que representa la manera en que se disponen en el documento de las t-uplas a extraer, o un subelemento (puede haber elementos que simplemente sirvan para agrupar subelementos, pero en los que no se extraiga ningún dato “propio”).

Un patrón DEXTL estará compuesto fundamentalmente por los siguientes tipos de componentes (más adelante en este documento, se dará una descripción más detallada de la sintaxis y composición de los patrones. Considérense estas líneas como una introducción a nivel intuitivo):

• Separadores: sirven para que el sistema sea capaz de distinguir dónde empieza o acaba, dentro de un patrón, un determinado atributo, así como dónde empieza o termina una determinada t-upla. En un patrón habrá básicamente dos tipos de separadores:

• Cadenas de caracteres: concuerdan con porciones del documento representando información para el usuario. Se representan entrecomilladas en el patrón.


Sintaxis Básica 6

• Marcas de formato: se utilizan para representar separadores constituidos por alguna expresión regular sobre etiquetas HTML Por ejemplo, en HTML existen un conjunto de marcas que permitan especificar un retorno de carro (o ‘fin de línea’). Puede ser muy útil definir una marca EOL como una expresión regular que concuerde con dichas marcas, proporcionando así una manera simple y altamente legible de representar los retornos de carro en los patrones.

Las marcas de formato se definen mediante expresiones regulares a las que se asigna un nombre. Las marcas se definen para proporcionar una manera sencilla y legible de representar expresiones regulares complejas que aparecen frecuentemente en la información para la herramienta visualizadora. Es importante destacar que las porciones del documento representando información de formato que no concuerden con ninguna marca de formato, son ignoradas por el sistema.

• Nombres de atributos atómicos: se situarán en la posición del patrón en la que aparece el valor de dicho atributo dentro de la representación gráfica de las t-uplas de R. Deben prefijarse con el carácter ‘:’. Concuerdan con las porciones del documento que representan información para el usuario y que se encuentran entre dos separadores. También es posible tener atributos auxiliares que no pertenezcan a R, pero cuyo valor sea interesante recoger para alguna operación o cálculo. Los atributos auxiliares se prefijan con ‘::’.

• Etiqueta ‘IRRELEVANT’: funciona de manera similar a los nombres de atributos en R, pero representa una porción del patrón que no se desea asignar a ningún atributo de R.

• Marcas de opcionalidad: son “¿” y “?” y permiten delimitar zonas del patrón que pueden aparecer o no. Es también posible utilizar el formato “/? <OPCIONAL> /?”.

• Marcas para identificar porciones del patrón alternativas: en un patrón puede aparecer una expresión del estilo ‘(subpatron1 | subpatron2)’, indicando que en esa zona del patrón puede aparecer o bien algo que concuerde con ‘subpatrón1’ o bien algo que concuerde con ‘subpatrón2’

Además, existen las marcas para identificar elementos o especificaciones alternativas. Por ejemplo, en algunas tiendas electrónicas, cuando una búsqueda ofrece un solo producto como resultado, se salta directamente al formato de ‘página de detalle del producto’ en lugar de a la habitual página de ‘resultados de búsqueda’. Sin embargo, antes de realizar la búsqueda no es posible saber si ésta va a devolver como resultado uno o varios productos, con lo que no es posible determinar a priori que patrón debe utilizarse para extraer las t-uplas de la relación. DEXTL proporciona una funcionalidad para tratar este tipo de casos que consiste en definir patrones para extraer t-uplas de todos los posibles formatos de documento y separarlos con el símbolo ‘||’. El programa DEXTL intentará en primer lugar el primer patrón. Si no encuentra t-uplas que concuerden, intentará el segundo y así sucesivamente. Dado que el programa intentará primero el patrón situado en primer lugar, es conveniente colocar en dicha posición al patrón más frecuente.

Ejemplo: Supongamos una fuente web con información sobre libros, modelada mediante una relación R={TITULO, AUTOR}. Supongamos que el siguiente fragmento de HTML representa la información que la fuente ofrece sobre un determinado libro:


Sintaxis Básica 7

Figura 4

Figura 5

Figura 6

<br> Michael <b> Crichton </b> <br> <a href=”/cgibook.jsp?id=1256790”>Title: Jurassic Park </a><br>

Fragmento HTML con Datos sobre un Libro.

Para representar con comodidad patrones capaces de extraer datos desde páginas HTML se puede definir una serie de marcas de formato, para representar las maneras habituales de separación mediante etiquetas en HTML. Por lo tanto, para poder representar un retorno de carro en el patrón, se puede definir la marca de formato EOL como una expresión regular que comprenda todas las posibles maneras que hay en HTML de representar un retorno de carro o fin de línea (como, por ejemplo, usando la marca ’<br>’). Si bien, hay más maneras de representar un retorno de carro en HTML, una definición simple para EOL, útil en muchos casos, podría ser la siguiente:

EOL:=(“<br>”|”</p>”|”</tr>”)

Definición de EOL

En la definición superior, se asocia la marca EOL con una expresión regular que concordará con la información para la herramienta visualizadora contenida en el documento, cada vez que aparezca o bien la marca ’<br>’ o bien la marca ‘</p>’ o bien la marca “</tr>”. En esas condiciones, el programa DEXTL analiza los tokens de la siguiente manera:

1. Token de tipo EOL. Correspondiente al primer ‘<br>’.

2. Token de tipo TEXTO, conteniendo el valor ‘Michael Crichton’. Nótese que las marcas ‘<b>’ y ‘</b>’ son ignoradas a todos los efectos, ya que constituyen información para la herramienta de visualización que no concuerda con ninguna de las marcas de formato definidas.

3. Token de tipo EOL. Correspondiente al segundo ‘<br>’.

4. Token de tipo TEXTO, conteniendo el valor ‘Title: Jurassic Park’. Nótese que las marcas ‘<a href=...>’ y ‘</a>’ son ignoradas a todos los efectos, ya que no concuerdan con ninguna de las marcas de formato definidas.

5. Token de tipo EOL. Correspondiente al tercer ‘<br’>.

Para entenderlo mejor, supongamos ahora que se ha definido el siguiente patrón:

{ NAME=”R” :AUTOR EOL “Title:” :TITULO EOL }

Definición de un Patrón Sencillo

Dado este patrón, el programa DEXTL detectará una ocurrencia del patrón cuando reciba la siguiente secuencia de tokens: TEXTO, EOL, TEXTO, EOL. Además el segundo token TEXTO tiene que cumplir una restricción adicional: debe ser conforme a la expresión regular que va implícita en la porción del patrón [“Title:” TITULO], y que en este caso, determina que el valor asociado a dicho token debe comenzar por la cadena “Title:”


Sintaxis Básica 8

Como puede verse, para el extracto de código HTML anterior, los cuatro últimos tokens constituyen una secuencia que concuerda con el patrón. Una vez detectada dicha secuencia de tokens, las acciones realizadas serán las siguientes:

• Crear una nueva t-upla de la relación.

• Asignar el valor del primer token TEXTO al campo AUTOR de la nueva t-upla. En este ejemplo concreto, el valor que tomará el campo AUTOR será ‘Michael Crichton’.

• Asignar al campo TITULO el resultado de aplicar al valor del segundo token TEXTO, la expresión regular construida implícitamente mediante el uso de separadores del tipo cadena de caracteres, que consiste, en este caso, en suprimir la subcadena ‘Title:’. Por lo tanto, para nuestra t-upla ejemplo, el valor para el campo TITULO será ‘Jurassic Park’.

Ejemplo: consideremos el ejemplo de la Figura 7, que representa el aspecto en un navegador de Internet de la página HTML devuelta como resultado de una búsqueda en una tienda online de libros. En la Figura 78, se muestra el código HTML asociado a la representación del primer libro.

Figura 7 Resultado de búsqueda de librería electrónica

Observando estos dos resultados con detenimiento, se ve que no tienen exactamente la misma estructura, pues el primero de ellos ofrece información acerca de la reducción de precio por descuento con respecto al original. El código HTML del primer resultado de la búsqueda es el siguiente:


Sintaxis Básica 9

Figura 8

Figura 9

<font size="-1" face="arial, helvetica, sans-serif"><A href="/booksearch/isbnInquiry.asp?userid=2N3SK9Y2P7&mscssid=JF86DUA3QD498J283583M4SBG9PQ0UL7&isbn=1861003668"> <b>Beginning Java 2 - Jdk 1.3 Version</b> </a></font><br> <font size="-1" face="arial, helvetica, sans-serif"> <font color="#aa0000">In Stock:Ships within 24 hours . </font><br>Ivor Horton / Paperback / Wrox Press, Inc. / <font size="-1" face="arial, helvetica, sans-serif">March 2000<br> Our Price: <font color="#aa0000">$39.99</font>, You Save <font color="#aa0000">20%</font><br> </font></TD>

Código HTML de resultado de búsqueda de librería electrónica

En este caso el esquema de los datos a extraer puede modelarse mediante un único elemento no atómico llamado LIBRO. Este elemento está compuesto por los subelementos atómicos: TÍTULO, AUTOR, FORMATO, PRECIO y DESCUENTO. A continuación se muestra el programa DEXTL que obtendría los ítems de información asociados al elemento LIBRO. Suponemos que se utiliza un único separador de tipo marca de formato: EOL.

{NAME=”LIBRO” :TITULO EOL IRRELEVANT EOL :AUTOR “/” :FORMATO “/” IRRELEVANT EOL “Our Price:” :PRECIO ¿“,You Save” :DESCUENTO EOL? }

patrón DEXTL de obtención de elementos de librería electrónica

Una vez definido el patrón de las t-uplas del elemento LIBRO, el sistema buscará las ocurrencias de ese patrón en la página. La asociación de información de la página con los ítems que se desean capturar viene dado por la siguiente sucesión de acciones:

1. Token de tipo TEXTO con el valor asociado ‘Beginning Java 2 - Jdk 1.3 Version’. Posteriormente se asocia este token con el atributo TITULO.

2. Token de tipo EOL, correspondiente con el primer ‘<br>’.

3. Token de tipo TEXTO, con el valor asociado ‘In Stock:Ships within 24 hours.’ Este token se asocia con el identificador IRRELEVANT, que es un identificador reservado utilizado por DEXTL para descartar datos.

4. Token de tipo EOL, correspondiente con el segundo ‘<br>’.


Sintaxis Básica 10

5. Token de tipo TEXTO, con el valor asociado ‘Ivor Horton / Paperback / Wrox Press, Inc. / March 2000’. DEXTL divide este valor a partir del patrón ’:AUTOR “/” :FORMATO “/” IRRELEVANT’, obteniendo los ítems AUTOR=Ivor Horton, FORMATO=Paperback, y descartando Wrox Press, Inc. / March 2000

6. Token de tipo EOL, correspondiente con el tercer ‘<br>’.

7. Token de tipo TEXTO, con el valor asociado ‘Our Price: $39.99, You Save 20%’. DEXTL asocia este valor con el patrón ‘“Our Price:” :PRECIO ¿“,You Save” :DESCUENTO?”’ para obtener los ítems PRECIO=$39.99, y DESCUENTO=20%. Es importante darse cuenta de que la obtención del ítem DESCUENTO es opcional. El segundo resultado del ejemplo es igualmente válido, aunque no provea ningún descuento.

8. Token de tipo EOL, correspondiente con el último ‘<br>’.

3.2 AMBIGÜEDAD DE PATRONES Y DELIMITACIÓN DEL ESPACIO DE BÚSQUEDA

Dado que DEXTL funciona según un enfoque que consiste en buscar las ocurrencias de un determinado patrón a lo largo de todo el documento, existe el problema potencial de que el patrón definido sea ambiguo. Lo que esto quiere decir es que es posible que haya porciones del documento que concuerden con el patrón pero que no sean realmente t-uplas de la relación. La mayor parte de las veces esta situación puede evitarse alargando la especificación del patrón a reconocer con partes que, aunque no se deseen extraer, eviten la ambigüedad. Sin embargo, en otras ocasiones, esto no es tan sencillo. Un ejemplo típico se muestra a continuación. Ejemplo: La Figura 10 muestra el formato gráfico utilizado por una tienda de libros en Internet para mostrar la información de sus productos.

Figura 10 Resultados Tabulados de una Tienda de Libros

Como puede verse, la información de los productos aparece tabulada. Esto tiene el inconveniente de que la fila cabecera de la tabla puede no ser fácil de distinguir de los resultados reales si sólo hemos definido la marca de formato que es más intuitiva en este caso: TAB:=”</td>”. De hecho un programa como el siguiente es ambiguo, ya que devolvería la fila cabecera como si fuese una t-upla válida de la relación ‘Libro’:


Sintaxis Básica 11

Figura 11

Figura 12

{NAME=”LIBRO” :TITULO TAB :AUTOR TAB :PRECIO TAB }

Patrón Ambiguo

Si bien en prácticamente todos los casos y también en éste en particular, una cuidadosa definición de marcas deformato o el uso de las funcionalidades de tratamiento de subrelaciones (ver apartado siguiente), permite definir un patrón no ambiguo, es evidente que sería más sencillo y rápido poder definirlo de una manera más intuitiva y sin hacer uso de marcas de formato adicionales definidas específicamente para cada documento y que, casi con toda seguridad, no serían reusables. Para solucionar problemas como el planteado en el ejemplo anterior, el sistema ofrece la posibilidad de delimitar la parte de un documento donde se desea buscar concordancias con un determinado patrón. Dentro de un determinado elemento del programa DEXTL, esto puede hacerse con la claúsula FROM de un elemento. Esta claúsula se especifica utilizando las construcciones ‘FROM-END_FROM’ y marca TO. La claúsula FROM se utiliza para delimitar por arriba (esto es desde el principio del documento hacia el final del mismo) la zona de búsqueda de concordancias. El formato de esta construcción se muestra a continuación:

{ ... FROM Patrón Desde END_FROM Patrón Principal Del Nivel ... }

Uso de FROM y END_FROM

Donde ‘Patrón Desde’ es un patrón DEXTL construido de la misma manera que los patrones habituales, y del cual, cuando se encuentra la primera ocurrencia, se abandona la búsqueda del mismo, pasándose a buscar ocurrencias del patrón principal del elemento. Si no se encuentra ninguna ocurrencia de ‘Patrón Desde’, el conjunto de t-uplas extraído para el elemento será vacío. Como puede verse, la construcción ‘FROM-END_FROM’ debe utilizarse dentro de la especificación de un elemento, antes de la definición de los patrones y/o subelementos de la claúsula de extracción del elemento. En cuanto al patrón TO, su función es simétrica pero delimitando por abajo la zona de búsqueda de concordancias. El patrón TO debe insertarse entre los símbolos ‘<’ y ‘>’ inmediatamente antes de la marca de fin del subpatrón ‘}’. Si no se incluye patrón TO, se asume implícitamente que ésta es el fin del documento actual. Otro uso muy importante del patrón TO se produce en el contexto del tratamiento de subrelaciones. De esta manera, para el ejemplo anterior, la siguiente especificación soluciona el problema de ambigüedad sin necesidad de definir marcas de formato adicionales.


Sintaxis Básica 12

Figura 13

Figura 14

{ FROM “Titulo” TAB “Autor” TAB “Precio” TAB END_FROM :TITULO TAB :AUTOR TAB :PRECIO TAB }

Solución del Problema de Ambigüedad

Ejemplo: El siguiente programa DEXTL busca ocurrencias del patrón Patrón en las dos zonas del documento delimitadas de la siguiente manera:

• La primera zona abarca desde la primera ocurrencia en el documento de PatrónDesde1 hasta la primera ocurrencia en el documento de PatrónHasta1 posterior a PatrónDesde1.

• La segunda zona abarca desde la primera ocurrencia en el documento de PatrónDesde2 posterior a la primera ocurrencia de PatrónHasta1, hasta la primera ocurrencia en el documento de PatrónHasta2 posterior a PatrónDesde2.

{ ... FROM PatrónDesde1 END_FROM Patrón1 <PatrónHasta1> } { ... FROM PatrónDesde2 END_FROM Patrón2 <PatrónHasta2> }

Aplicación de un Patrón a Dos Zonas

Con esta especificación, el programa DEXTL empieza buscando el patrón PatrónDesde1. Mientras no se encuentre, no se busca ningún patrón más (si se llega al final del documento se acaba el proceso de extracción). Si se encuentra el patrón PatrónDesde1 se empiezan a buscar a la vez los patrones Patrón1 y PatrónHasta1. Mientras no se encuentre PatrónHasta1 se van comunicando como resultados todas las ocurrencias de Patrón1. Cuando se encuentra PatrónHasta1, se sale del elemento actual (en este caso las primeras { … }). Por tanto deja de buscarse Patrón1, y se pasa a las segundas { ... }, donde se repite el mismo proceso. Es importante tener en cuenta que los resultados que se emparejan con los patrones de delimitación (en este caso, PatrónHasta1 y PatrónHasta2 no se comunican ni almacenan, ya que son patrones que sólo sirven para delimitar el espacio de búsqueda. Otra funcionalidad de los patrones FROM que puede ser útil es que pueden incluirse en ellos atributos correspondientes al elemento donde este incluido. Los valores que se asignen a esos atributos durante el proceso de búsqueda de ocurrencias del patrón, se añadirán luego a todas las t-uplas de la relación como atributos adicionales.


Sintaxis Básica 13

Figura 15

Como ejemplo, supongamos que estamos buscando información en una librería electrónica, que muestra el nombre del AUTOR al comienzo de la página, y a continuación un listado con todos sus libros y el precio. Utilizando un patrón FROM se puede obtener el nombre del AUTOR, y el resto de información en el patrón del elemento:

{ ... FROM … :AUTOR ... END_FROM ANCHOR :TITULO ENDANCHOR TAB :PRECIO EOL … }

Utilización del patrón FROM para obtención de información adicional

A cada ocurrencia del patrón del elemento que tendrá un atributo TITULO y otro atributo PRECIO, se le añaden los atributos que se obtuvieron en el patrón FROM, en este caso el atributo AUTOR, con el valor correspondiente.

3.3 RELACIONES Y SUBRELACIONES

3.3.1 Subrelaciones

Tal y como se comentó en el apartado 3.1 de este documento, un atributo de una determinada relación (es decir, de un determinado elemento) puede ser a su vez una relación con sus propios atributos. DEXTL proporciona soporte para tratar estos casos mediante la disposición jerárquica de diferentes elementos DEXTL dentro de un mismo programa. Cuando esto ocurra se dirá que la subrelación asociada al atributo “es hija” de la relación que contiene el atributo. Para que el sistema sea capaz de extraer t-uplas de una subrelación es necesario definir un nuevo elemento para ellas. Cada elemento tiene un nombre, que debe coincidir con el de la relación o subrelación cuyas t-uplas extrae y que se indica con la notación ‘NAME=”NOMBREELEMENTO”’, donde NOMBREELEMENTO es el nombre asignado al elemento. La manera de expresar la especificación del subelemento es incluirla entre los símbolos ‘{‘ y ‘}’. Se dirá que el patrón que trata de extraer t-uplas de la subrelación pertenece a un subelemento con respecto a aquel que busca t-uplas de la relación padre. Además, para que el sistema sea capaz de saber cuando debe dejar de buscar t-uplas de la subrelación y volver a buscar t-uplas de la relación o elemento superior, es necesario indicar un patrón que delimite el final de la subrelación. Este patrón, llamado patrón TO, constituye una marca de fin de la subrelación y debe insertarse entre los símbolos ‘<’ y ‘>’ inmediatamente antes de la marca de fin del subelemento ‘}’. Si no se incluye un patrón TO, se asume implícitamente que ésta es el fin del documento actual. Un detalle importante es que el texto que causa que se encuentre el patrón TO de la subrelación, es devuelto a la entrada una vez que se ha abandonado el subelemento. De esta manera, dicho texto será considerado de nuevo en el elemento padre. Para el patrón de cada relación o subrelación pueden usarse marcas de formato diferentes. En realidad, cada patrón contenido en un bloque entre ‘{‘ y ‘}’ puede especificar su propio Juego de Marcas de formato poniendo antes de la definición del patrón la expresión ‘SET ”NOMBRE”’, donde NOMBRE representa el nombre del Juego de Marcas de formato que se desea utilizar. Es importante resaltar que el patrón que especifica la marca de fin de una subrelación


Sintaxis Básica 14

utiliza el Juego de Marcas del patrón que se esté analizando en cada momento (esto es debido a que cada patrón del elemento puede tener un juego de marcas distinto). Ejemplo: Consideremos una tienda electrónica de películas representada por la relación R={TITULO, ACTORES, DIRECTOR, GENERO, RESUMEN, EDICION{DESCRIPCION, FORMATO, PRECIO}}.

Figura 16 Salida de una Tienda Electrónica de Películas

La Figura 16 muestra un ejemplo en el que se observa un fragmento de una página web en la que se representa gráficamente una t-upla de R. Para construir esta especificación definiremos un único Juego de Marcas conteniendo tres marcas de formato: la ya habitual EOL y dos nuevas a las que llamaremos TAB y ENDTABLE. TAB representa en HTML una tabulación. Para ello, utilizaremos la marca de fin de celda en HTML “</td>”. De esta manera TAB=”</td>”. ENDTABLE representa el fin de una tabla en HTML. Así, ENDTABLE=”</table>”. El programa DEXTL que sería capaz de extraer t-uplas con este formato sería la siguiente:


Sintaxis Básica 15

{ NAME=”R” :TITULO “(“ IRRELEVANT “)” EOL “Starring:” :ACTORES EOL “Director:” :DIRECTOR EOL “Synopsis:” :RESUMEN EOL IRRELEVANT EOL IRRELEVANT EOL “Genre:” :GENERO EOL PATTERN EDICION { FROM “Description:” TAB “Format:” TAB “List:” TAB “Price:” TAB “Availability:” TAB END_FROM :DESCRIPCION TAB :FORMATO TAB IRRELEVANT TAB :PRECIO TAB <ENDTABLE> } }

Figura 17

Figura 18

Patrón

La Figura 18, muestra el codigo HTML asociado a la Figura 17 pero habiendo suprimido todas aquellas marcas o etiquetas HTML que, al no concordar con ninguna de las definiciones de marcas de formato, son ignoradas por el programa DEXTL, y que constituyen la mayor parte del documento.

Small Time Crooks (2000)<BR> Starring: Woody Allen, Tracey Ullman<BR> Director: Woody Allen<BR> Synopsis: Manic crime comedy about an affable ex-con (Allen) cooking up a cunning bank robbery while working in a restaurant.<BR> Runtime: 95 minutes<BR> MPAA Rating: PG<BR> Genre: Comedy<BR> </TD> Description:</TD>Format:</TD>List:</TD>Price:</TD>Availability:</TD> Small Time Crooks (Widescreen)</TD>DVD</TD>$26.99</TD> $20.99</TD>Pre-Order</TD> </TR> Small Time Crooks</TD>VHS</TD>$14.99</TD>$10.49</TD>Pre-Order</TD> </TR> Small Time Crooks (Spanish Subtitles)</TD>VHS</TD>$14.99</TD>$10.49</TD>Pre-Order</TD> </TR> </TABLE>

HTML de la Figura 16 sin las Etiquetas irrelevantes

El análisis del documento funcionará ahora de la siguiente manera:

• Hasta llegar al comienzo de la subrelación funciona de la misma manera que se ha visto hasta el momento.


Sintaxis Básica 16

• Cuando, para una t-upla, llega al momento en que tiene que empezar a buscar t-uplas de la subrelación:

o Realiza el cambio de Juego de Marcas si es distinto del elemento padre (en este caso no es así).

o Comienza a buscar simultáneamente el patrón de las t-uplas de la subrelación y el patrón de marca de fin de la subrelación.

o La búsqueda de t-uplas de la subrelación se desarrolla de la misma manera que la búsqueda de t-uplas en un elemento padre.

o Cuando se encuentra la marca de fin de la subrelación, el conjunto de t-uplas de la subrelación extraídas pasan a ser el valor del atributo correspondiente de la t-upla del elemento padre. Además se devuelve a la entrada el texto que desencadenó el reconocimiento de la marca de fin.

• Al finalizar el tratamiento del subelemento, se prosigue buscando los atributos que falten de la t-upla del elemento padre.

Existe una restricción en el uso de subrelaciones, que es la siguiente: cuando un elemento de un programa DEXTL tiene como primer atributo una sub-relación (i.e. un atributo no atómico), el sistema tiene que emparejar al menos una ocurrencia de la sub-relación antes de poder emparejar el patrón TO. Por tanto el número de ocurrencias de los subelementos que estén como primer componente de un elemento estará entre 1 y n, en lugar de entre 0 y n.


Sintaxis Avanzada 17

Figura 19

4 SINTAXIS AVANZADA

Esta sección describe conceptos avanzados de la sintaxis que debe emplearse para escribir especificaciones que permitan la extracción de t-uplas desde páginas web y de texto semi-estructurado. Se asume que el lector está familiarizado con la terminología utilizada en las secciones anteriores.

4.1 ATRIBUTOS CON VALOR FIJO Y CON VALOR POR DEFECTO

En la especificación de un patrón, es posible indicar valores por defecto para los atributos de las t-uplas a extraer con el formato NOMBRE=”Valor”, donde NOMBRE es el nombre del atributo y “Valor” es el valor que se le desea asignar. Estas asignaciones deben ir en la especificación al comienzo del patrón. Esta funcionalidad es útil fundamentalmente en tres casos:

• Cuando algún atributo de la relación aparece sólo en ciertas t-uplas (y, por lo tanto, aparece en una parte opcional del patrón) y se le desea asignar un valor por defecto en aquellos casos en los que no aparezca.

• Cuando en una determinada fuente, todas las t-uplas toman un mismo valor para un determinado atributo, con lo que dicho atributo ya no aparece representado en los resultados. En ese caso, el atributo no aparecerá en el patrón.

• Cuando necesitamos algún valor auxiliar para realizar alguna operación o cálculo. Si no queremos, como será lo normal en estos casos, que se devuelvan como atributos de las t-uplas de la relación, basta con prefijar el atributo con ‘::’.

Ejemplo: Considérese una tienda de libros en Internet modelada según la relación R={TITULO, AUTOR, PRECIO, GASTOSDEENVIO}. Supóngase que la tienda carga habitualmente en cada libro un coste adicional de 4 euros en concepto de gastos de envío. Sin embargo, en aquellos casos en los que el libro es especialmente voluminoso o pesado, puede cargar un coste superior y, en ese caso, lo indica en la información que muestra sobre el libro. Para tratar esta situación podría definirse un patrón de la siguiente forma:

{NAME=”LIBRO” GASTOSENVIO=”4 euros” ... ¿.... :GASTOSENVIO....? ... }

Patrón

Como puede verse el patrón contiene el atributo GASTOSENVIO en una porción variable del patrón. Para aquellas t-uplas en las que dicha parte aparezca, GASTOSENVIO tomará el valor obtenido por el patrón. En otro caso, tomará el valor fijado por defecto, que es la cadena de caracteres “4 euros”.



Figura 20

Figura 21

Figura 22

4.2 SEPARADORES VORACES

Los separadores del tipo cadena de caracteres funcionan tratando de encajar con la primera ocurrencia del separador dentro del token de tipo TEXTO correspondiente. Sin embargo, a veces es útil que los separadores traten de encajar con la última ocurrencia del separador dentro de la secuencia de tokens. Para ello basta prefijar el separador con el carácter ‘:’. A este tipo de separadores se les llama “voraces”. Ejemplo: Supóngase una tienda electrónica de libros que represente los diferentes autores de un libro separados por comas y que utilice este mismo separador para separar la lista de autores del precio del libro:

... Ron Rivest, Rick Adleman, 12 euros; ...

Presentación de Resultados en una Fuente Web

Si escribiésemos:

... :AUTORES “,” :PRECIO “;” ...

Especificación Errónea

Entonces se asignaría al atributo AUTORES el valor ‘Ron Rivest’ y a PRECIO el valor ‘Rick Adleman, 12 euros’, lo cual probablemente no es el resultado deseado. Sin embargo podemos indicar al sistema que encaje el atributo AUTORES con el texto encontrado hasta la última “,” que precede al patrón :PRECIO “;”, escribiendo el carácter “:” antes de “,”:

... :AUTORES :”,” :PRECIO “;” ...

Especificación correcta con separadores voraces

Se asignaría a AUTORES el valor ‘Ron Rivest, Rick Adleman’ y a PRECIO el valor ‘12 euros’.

4.3 DEFINICIÓN DE MARCAS DE FORMATO

Tal y como se ha comentado previamente, una marca de formato viene definida por una expresión regular. Cada marca de formato lleva asociada un nombre. El formato para las definiciones de marcas de formato es: 'NOMBRE:=Expresión'

Donde NOMBRE es el nombre de la marca y Expresión es la expresión regular. Ejemplo: Para HTML podemos definir la marca EOL vista anteriormente de la siguiente manera: EOL:= (“<br>” | “</p>” | ”</tr>”).



Al mismo tiempo que se detectan las marcas de formato, es posible definir parámetros (o identificadores) a los que se pueden asignar ciertos valores, y que se pasarán a la aplicación usuaria para todas las marcas de ese tipo encontradas. Estos parámetros pueden ser usados posteriormente en los patrones DEXTL de extracción. El valor que se le asigne a un parámetro puede ser:

• Una constante. Ejemplo: ANCHOR(URL=”http://www.denodo.com”)

• Una variable del contexto. Ejemplo: ANCHOR(URL=@VARIABLE). En este caso el valor que se le asigne al parámetro será el valor que tenga la variable VARIABLE en el contexto actual en el momento en que se obtiene la marca de la página.

• Un atributo HTML. Este es el caso más común. Ejemplo: ANCHOR(URL=href). Tomará el valor asignado al atributo HTML indicado (en este caso href).

• Una función. Las funciones ejecutan una determinada tarea y devuelven un valor como resultado de su ejecución. Este valor será el que se asigne al parámetro. Las funciones pueden tomar como parámetros cualquiera de los elementos anteriores o incluso otra función, y sus valores concretos se determinarán cada vez que se ejecute la función. La sintaxis utilizada es ^NombreFunción(param1, ...,paramN). En la actualidad, DEXTL incluye una única función llamada CompleteURL. Esta función recibe como parámetros una URL relativa (e.g. /products?id=3025) y una URL base (e.g. http:///www.bookshop.com) y las combina para devolver una URL absoluta (e.g. http://www.bookshop.com/products?id=3025). En la sección 4.3.1 se muestra un ejemplo de utilización de CompleteURL.

Ejemplo: Se desea definir una marca de formato ANCHOR que concuerde con la marca ‘<A ...>’ del lenguaje HTML. Supongamos además que se quiere obtener el valor del atributo ‘href’ contenido en dicha marca HTML, asignándoselo a un identificador llamado URL. Se puede definir de la siguiente manera: ANCHOR(URL=href):=”<a” [^>]* “ >”. De esta manera, cuando se encuentre alguna porción de texto en el documento que concuerde con la expresión regular, además de identificar una ocurrencia de la marca de formato ANCHOR, se asignará al identificador URL la porción del texto que se encuentre asignada al atributo href de la marca “<a” que ha provocado la concordancia. La expresión regular utilizada para especificar las marcas tipo “<a” se construye de la siguiente manera: se exige que comience por la cadena de caracteres “<a”. Posteriormente a dicha cadena, puede ir opcionalmente cualquier combinación de caracteres diferentes de ‘>’ (esto es lo que quiere decir la porción ‘[^>]*’) y, finalmente, irá el carácter ‘>’, que cierra la marca HTML. Estas expresiones regulares utilizan el formato de expresiones regulares de JFLEX [[FLEX]]. El valor de los identificadores obtenidos de esta manera puede ser utilizado en los patrones, por ejemplo para asignar el valor obtenido a alguno de los campos de las t-uplas extraídas. La notación utilizada para esto es la siguiente: ‘NOMBREMARCAFORMATO(:ATRIB1=ID1,..., :ATRIBN=IDN)’, donde ATRIB1,..., ATRIBN son nombres de atributos en la relación cuyas t-uplas se están extrayendo e ID1,...,IDN son identificadores presentes en la definición de la marca de formato. De los atributos como ATRIB1, ATRIB2...ATRIBN diremos que están ligados a la marca ‘NOMBREMARCAFORMATO’. Ejemplo: Considérese una tienda electrónica de libros representada mediante la relación R={TITULO,AUTOR, PRECIO, ENLACEAMASINFO}, donde el campo ENLACEAMASINFO contiene una URL que permite acceder directamente a la página HTML de la tienda donde se proporciona información detallada sobre el producto. Si el aspecto gráfico de la salida es similar al mostrado en la Figura 7 y suponemos definida la marca ENLACE de la misma



Figura 23

manera que en el ejemplo anterior, además de la marca EOL, definida de la manera habitual, podríamos escribir el siguiente patrón para extraer las t-uplas de R.

{NAME=”R” ANCHOR(:ENLACEAMASINFO=URL) :TITULO EOL IRRELEVANT EOL :AUTOR “/” IRRELEVANT EOL “Our Price:” :PRECIO ¿“,” IRRELEVANT? EOL }

Patrón que Extrae Información de una Marca de Formato.

Otra nota importante al respecto de estos identificadores es que una marca que los tenga definidos encajará con una determinada porción de texto en el documento analizado sólo si las porciones referentes a dichos identificadores aparecen también. Para indicar que se desea que la marca encaje igualmente, aparezca o no en el documento la porción que encaje con el identificador, hay que indicarlo con los símbolos “¿” y “?” (o “/?” y “/?”). Por ejemplo si está definida en la especificación del patrón una marca ANCHOR(:REFMASINFO=URL) y DEXTL recibe del documento una marca ANCHOR() sin valor para URL, no encajaría. Sin embargo, si se hubiese puesto en la especificación ANCHOR(¿:REFMASINFO=URL?) o ANCHOR(/?:REFMASINFO=URL/?), sí lo haría. Por tanto, y resumiendo:

- Si la etiqueta <a…> no tiene atributo href, entonces se devolverá un token ANCHOR sin URL. - Si la etiqueta <a…> tiene atributo href , se devolverá un token ANCHOR con URL=valor_href - Ahora, si en la especificación tenemos ANCHOR(:REFMASINFO=URL)

- Si se recibe un token ANCHOR(), entonces el patrón no encajará. - Si se recibe un token ANCHOR(URL=valor_href), entonces el patrón encajará y se asignará a la

etiqueta :REFMASINFO el valor_href. - Si en la especificación se tiene ANCHOR(¿:REFMASINFO=URL?) o ANCHOR(/?:REFMASINFO=URL/?)

- Si se recibe un token ANCHOR() sin URL entonces el patrón encaja, pero no se asigna ningún valor a REFMASINFO (ni siquiera se crea el atributo).

- Si recibimos un token ANCHOR(URL=valor_href) entonces el patrón encaja y se asigna a :REFMASINFO el valor_href.

- Si en la especificacion se tiene ANCHOR() (o ANCHOR, pues son equivalentes) - Si se recibe un token ANCHOR() encaja. - Si se recibe un token ANCHOR(URL=valor_href) entonces el patrón encaja y no se hace ninguna

asignación de variables. Por último, cuando se definen las marcas se puede asignar el valor “true” a un atributo de la marca en función de si en la etiqueta HTML a la que se refiere la marca está presente un atributo (tenga el valor que tenga o incluso si no tiene ningún valor asignado). Por ejemplo, si se define una marca para la etiqueta OPTION puede interesar saber si es el seleccionado o no (es decir, si el atributo SELECTED está o no presente): OPTION(VALOR=value,SELECTED=¿selected?):="<option" [^>]* ">"



Figura 24

Al atributo "VALOR" de la marca se le asigna el valor del atributo "value" de la etiqueta HTML OPTION. Si el atributo "selected" está presente en la etiqueta HTML entonces se asigna el valor "true" al atributo "SELECTED" de la marca (en caso contrario no se asigna ningún valor).

4.3.1 Juegos de Marcas

Las marcas de formato se agrupan en Juegos de Marcas. Un Juego de Marcas no es más que una lista de definiciones de marcas de formato agrupadas bajo un nombre común. Los Juegos de Marcas pueden definirse con la siguiente sintaxis:

SET “NOMBREJUEGO” NOMBREMARCA1:=Expr1 ... NOMBREMARCAn:=Exprn ENDSET

Juego de Marcas

Donde NOMBREJUEGO es el nombre del Juego de Marcas, NOMBREMARCA1, ..., NOMBREMARCAn son nombres de marcas de formato y Expr1,...,Exprn son expresiones de definición de marcas de formato. Para facilitar su reutilización, los Juegos de Marcas pueden ser guardados en un fichero y ser incluidos posteriormente por las especificaciones que deseen usarlos. Los juegos de marcas existentes se encuentran en el directorio $DENODO_HOME/metadata/parsers/tagsets. Cada fichero se corresponde con la definición de un juego de marcas. Los juegos más relevantes son:

• STANDARD define las marcas ANCHOR, ENDANCHOR, EOL, TAB y FRAME de la siguiente forma:

SET "STANDARD" EOL:="</TD" [^>]* ">" [\n\r\t ]* "</TR" [^>]* ">"|"<BR"~">"|"<LI"~">"|"<P"~">"|"</TR" [^>]* ">"|"</OPTION" [^>]* ">"|"<DD"~">"|"<DT"~">"|"<DL"~">"|"</UL" [^>]* ">"|"</H1" [^>]* ">"|"</H2" [^>]* ">"|"</H3" [^>]* ">"|"</H4" [^>]* ">"|"</H5" [^>]* ">"|"</H6" [^>]* ">"|"</TH" [^>]* ">" ANCHOR(URL=^CompleteURL(href,@URLBASE)):="<a" [^>]* ">" FRAME(SRC=^CompleteURL(src,@URLBASE)):= "<frame " [^>]* ">" TAB:="</TD" [^>]* ">" ENDANCHOR:="</A" [^>]* ">" ENDSET Para la marca ANCHOR se ha definido el parámetro URL cuyo valor será el devuelto por la función CompleteURL. Esta función completa el valor extraído del href con el valor que tenga una variable especial del contexto de navegación llamada URLBASE. De esta forma, si el enlace extraído era relativo, se transformará en una URL completa. Para que la obtención del enlace absoluto funcione correctamente, esta variable debe ser añadida como un atributo con valor fijo en el programa DEXTL (ver sección 4.1). Si no existiese valor para URLBASE, se devolverá el enlace relativo. La marca FRAME también tiene definido un parámetro, SRC, que es similar al parámetro URL del ANCHOR.

• STANDARD_TEXTFRAGMENT. Con respecto al anterior, no incluye las marcas ANCHOR y ENDANCHOR y,

además, excluye los tags "BR" de la definición de la marca EOL. Esto es útil para recuperar como un único valor textos que puedan contener en su interior enlaces y/o retornos de carro.



Para que un nuevo juego de marcas definido por el usuario pueda ser utilizado en los programas DEXTL, es necesario generar e instalar previamente un “escáner” para el mismo. En la sección 4.7 se describe detalladamente este proceso. Finalmente, es muy mportante resaltar que dentro de una misma especificación pueden utilizarse diferentes Juegos de Marcas para las diferentes relaciones y subrelaciones involucradas en la especificación.

4.4 JERARQUÍA DE ELEMENTOS

En esta sección se describe la forma en que diferentes elementos DEXTL pueden ser dispuestos dentro de un mismo programa DEXTL. Un programa DEXTL puede tener varios elementos "raíz" (esto es, que no son subelementos de otro elemento padre). Cada elemento puede contener:

• Un nombre para las t-uplas de la relación representada por el elemento. La sintaxis es:

NAME="Nombre elemento" • Un Patrón DEXTL. Podrá contener:

o El Juego de Marcas que se quiere utilizar con él. Debe indicarse al comienzo del patron con la sintaxis:

TAGSET=”Nombre juego” Si no se indica nada, se utilizará el juego por defecto que se haya elegido para esa especificación (normalmente será el juego STANDARD).

o Sub-elementos anidados que representan subrelaciones (ver sección 3.3). Los subelementos

pueden tener los mismos componentes que un elemento raíz y además pueden especificar un parámetro adicional. Este parámetro representa el nombre del atributo del elemento padre que contendrá todas las t-uplas de datos del subelemento. Si no se indica, se tomará el mismo nombre especificado para cada t-upla del sub-elemento (a través de la construcción NAME). La sintaxis es:

LISTNAME="Nombre lista"

• En ambos tipos de elementos (raíces o sub-elementos) puede existir una marca de fin del elemento, a la

que llamamos patrón TO (cuya sintaxis fue descrita en la sección 3.3).

o En el caso de un subelemento, cuando se encuentra el patrón TO, se continua con la búsqueda de tuplas del elemento padre.

o En el caso de los elementos principales, cuando se encuentre el patrón TO se continuará

analizando la página buscando ocurrencias del siguiente elemento principal. Si no hubiese más elementos principales el proceso finalizaría. El final de página es también considerado como marca de fin para cualquier elemento.

Hay dos formas de definir subelementos:



Figura 25

• Entre los símbolos { y }: Las t-uplas extraidas para un subelemento se considerarán como el valor de un atributo de tipo subrelación asociado al elemento padre. Por ejemplo si tenemos un elemento PELICULA con atributos atómicos TITULO, ACTOR y un subelemento EDICION con atributos atómicos FORMATO y PRECIO, el esquema de los datos devueltos a la aplicación sería: {TITULO, ACTOR, EDICION{ FORMATO, PRECIO}}.

• Entre los símbolos {* y *}: los atributos extraídos del elemento padre se añaden a cada sub-elemento hijo. Es decir,los resultados extraidos se “aplanan” antes de ser devueltos a la aplicación. Por ejemplo si tenemos un elemento PELICULA con atributos atómicos TITULO, ACTOR y un subelemento EDICION con atributos atómicos FORMATO y PRECIO, el esquema de los datos devueltos a la aplicación sería: {TITULO, ACTOR, FORMATO, PRECIO}.

4.5 ESPECIFICACIONES ALTERNATIVAS

En ocasiones el formato en que están representadas las t-uplas de una determinada relación puede variar en función de la consulta realizada sobre la fuente, pero sin que sea posible determinar a priori cuál de los formatos de salida va a ser utilizado. Ejemplo: En muchas tiendas electrónicas, cuando una búsqueda ofrece un solo producto como resultado, se salta directamente al formato de ‘página de detalle del producto’ en lugar de a la habitual página de ‘resultados de búsqueda’. Sin embargo, antes de realizar la búsqueda no es posible saber si ésta va a devolver como resultado uno o varios productos, con lo que no es posible determinar a priori que patrón debe utilizarse para extraer las t-uplas de la relación. DEXTL proporciona una funcionalidad para tratar este tipo de casos que consiste en definir elementos DEXTL para extraer t-uplas de todos los posibles formatos de documento y separarlos con el símbolo ‘||’ para indicar que son elementos alternativos. El programa DEXTL intentará en primer lugar el primer elemento. Si no encuentra t-uplas que concuerden, intentará el segundo y así sucesivamente. Dado que el programa intentará primero el elemento situado en primer lugar, es conveniente colocar en dicha posición al elemento que representa al formato más frecuente. Así, para el ejemplo anterior, podría construirse una especificación del siguiente tipo:

{ //Patrón de la página de resultado de búsqueda ..... } || { //Patrón de la página de detalle de producto ..... }

Especificaciones Alternativas

NOTA: Las especificaciones alternativas sólo pueden utilizarse en patrones de primer nivel. Si las alternativas se encuentran en niveles más profundos, se debe utilizar el formato (patrón1 | patrón2) dentro del patrón concreto.



4.6 ESCÁNERS

Para realizar el análisis léxico de los documentos sobre los que se ejecuta el proceso de extracción, el intérprete DEXTL utiliza un tipo de componente llamado escáner. Cada programa DEXTL debe obligatoriamente especificar el escáner a utilizar durante el pro ceso de extracción utilizando la directiva #include para indicar el fichero correspondiente a la definición de un escáner:

#include “scanners/nombre_escaner” Los escáners son importantes porque, para que un juego de marcas pueda ser utilizado dentro de un programa DEXTL, es necesario que dicho juego esté incluido dentro del escáner indicado por el programa. Entre otros, Denodo ITPilot suministra los escáners StandardLexer y StandardLexerJS que contienen los juegos de marcas utilizados más habitualmente (STANDARD y STANDARD_TEXTFRAGMENT. Ver sección 4.3). La diferencia entre ambos escáners es que StandardLexer elimina de las páginas HTML objetivo el código Javascript, previamente a aplicar el programa DEXTL sobre ellas. Por el contrario, StandardLexerJS mantiene el código Javascript. En la mayor parte de casos, StandardLexer simplifica la construcción de los programas DEXTL y es, por lo tanto, la opción recomendada. Si se desea utilizar nuevos juegos de marcas creados por el usuario, entonces es preciso crear un nuevo escáner que contenga dichos juegos. La sección 4.7 describe los pasos necesarios para ello.

4.7 GENERACIÓN E INSTALACIÓN DE NUEVOS ESCANERS

Los “escaners” son utilizados por el intérprete de DEXTL para realizar el análisis léxico de los documentos sobre los que se ejecuta el proceso de extracción. Para que un juego de marcas pueda ser utilizado dentro de un programa DEXTL es necesario que dicho juego esté incluido dentro del escaner utilizado. Véase la sección 4.6 para más información sobre los escaners disponibles en ITPilot. Si se desea añadir un nuevo juego de marcas al sistema es necesario generar e instalar un nuevo “escáner” para el mismo. Para ello es necesario crear un fichero de especificación de escáner que indique: 1) el tipo de lexer (también llamado esqueleto) a utilizar, 2) la definición de los juegos de marcas que se desea incluir en el escáner. Existen dos tipos de lexer disponibles en ITPilot: html_nojs y html_js. El primero de ellos elimina el código Javascript de las páginas HTML objetivo previamente a la aplicación del programa DEXTL sobre las mismas. Por el contrario, html_js no elimina dicho código. La eliminación del código Javascript suele simplificar la elaboración de los programas DEXTL y, por lo tanto, html_nojs es la opción recomendada. El tipo de lexer deseado se indica con la palabra reservada LEXERTYPE. El valor ha de seguir el formato “skeletons/nombre_tipolexer“. En cuanto a los juegos de marcas, la definición de cada juego será guardado en un fichero en la ruta $DENODO_HOME/metadata/parser/tagsets. Los juegos deseados serán incluidos en el escáner mediante el uso de la directiva #include “tagsets/nombre_fichero_juego”. A continuación se describe paso a paso el proceso completo de creación de un nuevo escáner:

1. Definir los nuevos juegos de marcas de acuerdo a lo descrito en la sección 4.3. Guardar cada juego en un fichero en la ruta $DENODO_HOME/metadata/parser/tagsets.

2. Escribir un fichero de especificación de escáner que indique el tipo de lexer y los juegos de marcas a utilizar en el nuevo escáner y guardarlo en la ruta $DENODO_HOME/metadata/parser/scanners. El nombre del fichero debe ser el nombre deseado para el escáner. Dentro del fichero se especificará un tipo de lexer y se incluirán los ficheros que



definen los juegos de marcas deseados. Más adelante en esta misma sección se incluye un ejemplo de fichero de especificación de escáner.

3. El siguiente paso es generar e instalar el escáner. Para ello debe utilizarse el script $DENODO_HOME/bin/ITPilot/gen_scanner.bat (o gen_scanner.sh en instalaciones Unix). Este script recibe como parámetro el fichero con la especificación del escáner.

4. Instalar el nuevo escáner en otros entornos de ITPilot. Para que el escáner generado esté disponible en todos los entornos que componen Denodo ITPilot (generación, ejecución y mantenimiento), es necesario repetir el proceso anterior en cada uno de ellos.

5. Para utilizar el nuevo escáner en un programa DEXTL debe utilizarse al comienzo del mismo la directiva: #include “scanners/nombre_escáner”

A continuación se muestra un ejemplo del proceso de creación de un escáner: 1. En primer lugar se definen los juegos de marcas a utilizar. En este caso,definiremos el juego standard y otro juego adicional al que llamaremos comentario. Los ficheros correspondientes se copiarán en $DENODO_HOME/metadata/parser/tagsets. SET "STANDARD" EOL:="</TD>" [\n\r\t ]* "</TR>" | "<BR>" | "<LI>" | "<P"~">" | "</TR>" | "</OPTION>" | "<DD>" | "<DT>" | "<DL>" | "</UL>" | "</H1>" | "</H2>" | "</H3>" | "</H4>" | "</H5>" |"</H6>" | "</TH>" ANCHOR(URL=^CompleteURL(href,@URLBASE)):="<a" [^>]* ">" FRAME(SRC=^CompleteURL(src,@URLBASE)):= "<frame " [^>]* ">" TAB:="</td>" ENDANCHOR:="</a>" ENDSET

Figura 26 Juego de Marcas STANDARD

SET "COMENTARIO" ANCHOR := "<a class=" [^>]* ">" ENDANCHOR := "</a>" ENDSET

Figura 27 Juego de Marcas COMENTARIO

2. Posteriormente, definiremos un escáner que incluya a ambos juegos. El fichero de especificación de escáner se guardará con el nombre deseado para el escáner en la ruta $DENODO_HOME/metadata/parser/scanners. En este caso utilizaremos el nombre “LexerComentario”: LEXERTYPE="skeletons/html_nojs" #include "juegos/standard" #include "juegos/comentario"

Figura 28 Escáner con Juegos de Marcas STANDARD y COMENTARIO



El juego “STANDARD” ya ha sido comentado previamente (ver sección 4.3). El juego “COMENTARIO” sólo utiliza los enlaces como marcas de formato. 3. A continuación, el nuevo escáner puede ser generado e instalado invocando el script gen_scanner.bat en la ruta $DENODO_HOME/bin/ITPilot/ pasándole como parámetro el nombre del escáner, LexerComentario. Para utilizar el nuevo escáner en un programa DEXTL, bastaría con especificar el nuevo escáner en un programa DEXTL mediante la directiva #include “scanners/LexerComentario”.

4.8 ESTRUCTURA DE UN PROGRAMA DEXTL

Los programas DEXTL se dividen en dos secciones, que no están separadas físicamente por ningún elemento pero que deben aparecer en el orden indicado:

• Sección de declaraciones

• Sección de especificación

4.8.1 Sección de Declaraciones

En esta sección se incluyen los siguientes elementos:

1. Nombre del Analizador Léxico (o escáner) a utilizar. Es obligatorio y debe aparecer al comienzo del programa DEXTL. Se incluirá el fichero con el escáner deseado (ver sección 4.6 para una descripción de los escáners disponibles y la sección 4.7 para saber cómo crear nuevos escaners). Se indica con:

#include “scanners/nombre_escaner”

Puede utilizarse el mismo escáner para todas las especificaciones que compartan los mismos Juegos de Marcas.

2. Nombre del esqueleto utilizado para generar el escáner correspondiente a la especificación. La herramienta de generación de especificaciones añade al programa DEXTL:

LEXERTYPE="esqueleto"

3. Nombre del Juego de Marcas por defecto para los patrones para los que no se especifique ninguno.

DEFAULTTAGSET = "Nombre juego"

4. Ficheros incluidos. Igualmente, la herramienta de generación de especificaciones indicará en el programa DEXTL qué otros programas externos están incluídos. El efecto será el mismo que si el contenido de ese fichero estuviese en el fichero actual en el lugar donde se encuentra el include. La sintaxis es:

#include "Nombre fichero"

5. Atributos con valor por defecto. Tienen un valor fijo para todos los ítems/resultados encontrados con la especificación, y los denominaremos atributos fijos:

NOMBRE[CONTEXTO]="VALOR"



Siendo el contexto opcional. Este contexto no debe confundirse con el contexto de navegación, sino que es información asociada a ese campo que se comunica junto con el valor asociado a él.

Es posible definir un atributo de valor fijo que se vaya a utilizar más adelante en el programa, pero que no se desee que su valor se comunique a la aplicación, en este caso, el formato es

:: NOMBRE[CONTEXTO]="VALOR"

Es posible asignar varios valores (valor multivaluado) a un atributo fijo:

NOMBRE [CONTEXTO] = {"VALOR1",”VALOR2”,...}

6. Juegos de Marcas que se deseen utilizar. Formato:

SET NOMBRE MARCA := EXPRESION MARCA := EXPRESION

... MARCA := EXPRESION

ENDSET

• Tal y como ya se comentó en la sección previa, es posible definir parámetros (o identificadores) asociados a una marca de formato, a los que se pueden asignar ciertos valores, y que se pasarán a la aplicación usuaria para todas las marcas de ese tipo encontradas.

4.8.2 Sección de Especificación

En esta sección se incluyen las especificaciones de extracción propiamente dichas.

4.9 ESCAPADO DE CARACTERES EN DEXTL

En los programas DEXTL pueden distinguirse dos tipos de cadenas:

- Las que interpolan valores de variables, que pueden contener variables (@VAR) o funciones. (ver sección 4.3). Estas cadenas se evalúan al realizar el proceso de análisis del programa, e incluye tanto los separadores de texto que aparezcan en los patrones y los valores de las etiquetas fijas (sección 4.1).

- Las que no interpolan, el resto de cadenas fijas que aparecen en la especificación. El delimitadores de las cadenas es la comilla doble, ‘ “ ‘. Por tanto, si es necesario que aparezcan como elemento de alguna cadena, ha de escaparse. Esto se realiza mediante el carácter de escape “\”. El carácter de escape también ha de escaparse si se desea utilizar como carácter de cadena. Por tanto: “cadena con símbolo \ como parte del contenido \” habría de escribirse como “cadena con símbolo \\ como parte del contenido \\”. Por otra parte, cuando se realiza una interpolación los caracteres ‘ { ‘, ‘ } ‘ y ‘ @ ‘ tienen un significado especial. Si se desea eliminar ese significado (p.e. para utilizarlos como parte del nombre de un atributo o para que ‘@’ no se refierea a una variable) deben escaparse. De nuevo el carácter de escape es ‘ \ ‘ que también debe escaparse cuando no quiere utilizarse como carácter de escape. Uniendo este último comentario con los anteriores, y en aras de aumentar la claridad de esta sección, se muestran a continuación algunos ejemplos de cómo quedarían las siguientes cadenas interpolables:

• @ => \\@



• ^ => \\^

• { => \\{

• } => \\}

• \ => \\\\

• “ => \”


Anexo A: Funcionalidad DEXTL obsoleta 29

5 ANEXO A: FUNCIONALIDAD DEXTL OBSOLETA

Este anexo describe y explica aquella funcionalidad provista por DEXTL que se considera obsoleta desde la versión ITPilot 4.0. Se mantiene por mantenimiento de compatibilidad hacia atrás, pero se desaconseja su uso.

5.1 PATRÓN TO CON DESCARTE DE INFORMACIÓN

Se puede acceder a una funcionalidad interesante utilizando la notación alternativa ‘<-’ y ‘->’ para abrir y cerrar los patrones TO. Cuando el programa DEXTL se encuentra con esta marca, descarta todo lo que quede del documento activo y accede al documento en el que estaba antes de entrar al subelemento, justamente en el punto donde se abandonó. Esto es útil cuando las t-uplas de una subrelación están en un documento distinto del de las t-uplas de la relación o elemento superior. Si al llegar a cierto punto de ese documento queremos dejar de buscar t-uplas de la subrelación y volver al documento anterior para seguir buscando t-uplas de la relación o elemento superior, entonces puede usarse esta notación especial. Debido a que ITPilot 4.0 aconseja la utilización de componentes de Extracción diferentes para diferentes páginas, esta funcionalidad queda como obsoleta.

5.2 CONTEXTOS PARA ATRIBUTOS

Otra funcionalidad ofrecida por el sistema consiste en la posibilidad de asociar un contexto a un determinado atributo. Un contexto permite asignar metainformación a un determinado atributo. Esta metainformación es pasada a la aplicación usuaria para que ésta pueda utilizarla a su conveniencia. Es importante resaltar que el formato de dicha metainformación es irrelevante desde el punto de vista de DEXTL. Es la aplicación usuaria la que recibirá la metainformación y es responsabilidad suya interpretarla y utilizarla. La notación utilizada es: ‘[MetaInformación]’, donde Metainformación es una cadena de caracteres con la metainformación que se desea asignar al atributo. Ejemplo: En una tienda electrónica que ofrece toda su información de precio en dólares, se desea especificar esta característica asociada al atributo PRECIO, de manera que la aplicación usuaria pueda realizar conversiones de moneda. Así, en el patrón para extraer t-uplas de dicha fuente, podría ponerse ‘...:PRECIO[DIVISA=DÓLAR]...’ asumiendo que el formato de metainformación ‘DIVISA=DÓLAR’ es entendido y tratado correctamente por la aplicación usuaria. Los contextos pueden también ser utilizados de manera más general. La asignación de estos contextos generales utiliza la sintaxis de atributos con valores fijos (ver apartado 4.1. Existen dos tipos de contextos generales:

• Contextos generales para todos los atributos de la especificación: Su sintaxis es como la de un atributo fijo de nombre "_". Ese contexto será añadido al contexto particular para cada atributo tratado.

En el siguiente ejemplo se asigna la metainformación de contexto "LENGUAJE=es,PAIS=ES,TIMEZONE=Europe/Madrid" a todos los atributos de la



especificación. Si un atributo concreto redefine alguna de estas propiedades, serán esos los valores que tendrán vigencia.

_="LENGUAJE=es,PAIS=ES,TIMEZONE=Europe/Madrid"

• Contextos generales para un atributo concreto: Su sintaxis es la de un atributo de valor fijo, con la salvedad de que al nombre del atributo se le añade como prefijo el carácter "_". Su alcance es menor que el del anterior: el contexto definido sólo se le añadirá al contexto del atributo indicado (en el ejemplo siguiente, al atributo FECHAFIN).

_FECHAFIN="TPATRON=d'dias' h'h' m'm' s's'"

Esta funcionalidad queda como obsoleta.

5.3 JERARQUÍA DE ELEMENTOS AUXILIARES

Existe otra manera de definir subelementos en DEXTL no documentada en el apartado 4.4:

Entre {- y -}: Los datos extraídos a través del subelemento no se considerarán como parte de los datos a devolver a la aplicación. Son útiles cuando queremos extraer datos de la página para realizar algún proceso intermedio.

5.4 ACCIONES

Dentro de un patrón de extracción de un elemento, puede especificarse una acción que se ejecutará cada vez que se encuentre una concordancia con ese patrón del elemento. Si la acción se define al final del patrón o en medio del mismo, la acción se ejecutará justo después de encontrar cada concordancia del patrón. Si se define antes del patrón, se ejecutará siempre antes de empezar a buscar una nueva ocurrencia. Como consecuencia de esto, una acción definida antes del patrón se ejecuta siempre al menos una vez al empezar a buscar el patrón, incluso aunque no se encuentre ninguna t-upla que concuerde con el mismo, mientras que una definida después del patrón sólo se ejecutará una vez encontrada alguna ocurrencia. (en caso de haber patrones con partes opcionales o alternativas solamente se ejecutan las acciones que están en las zona opcionales y alternativas que se utilizaron para emparejar con la ocurrencia). Las acciones se utilizan para ejecutar una operación arbitraria que es implementada por un código específico de la acción. Las acciones pueden recibir un conjunto de pares campo-valor para parametrizar su ejecución. El valor de un parámetro de una acción será una expresión compuesta por:

• Constantes. No es necesario ponerlas entre comillas.

• Variables del contexto. Siguiendo el habitual formato @NOMBRE (o @{NOMBRE} en caso de ser necesario delimitar hasta donde llega el nombre). Se sustituirán por su valor en el contexto en el momento de evaluarse la acción.

• Funciones. Siguiendo el formato: ^NOMBRE(param1,...,paramN). Los parámetros, que pueden a su vez ser constantes, variables o funciones, se evalúan en función del contexto y después a partir de esos


A

valores se evalúa la función. Tal y como ya se ha comentado, en la versión actual de DEXTL existe una única función disponible: CompletaURL, que fue descrita en la sección 4.3.

L

Decn E

E

Aape Dpg

5

D

a sintaxis para incluir una acción es la siguiente:

$NOMBREACCION(PARAM1=”VALOR1”,...,PARAMi=”@NOMBRE”)

nexo A: Funcionalidad DEXTL obsoleta 31

Figura 29 Sintaxis para una Acción

onde ‘NOMBREACCION’ es el nombre de la acción y ‘PARAM1,...,PARAMn’ son los nombres de los parámetros que spera la acción. Para indicar que el valor de un determinado parámetro (o un fragmento de él) debe recogerse del ontexto, se usa la notación ‘@NOMBRE’ donde ‘NOMBRE’ es la etiqueta que identifica en el contexto de avegación actual el valor deseado.

s posible llamar a las acciones pasando parámetros multivaluados. La sintaxis es:

PARAMETRO={"valor1","@variable1",”valor2@variable2”,...}

n caso de que solo se pase un valor pueden obviarse las llaves:

PARAMETRO="valor1"

l final de un elemento es posible incluir un conjunto de acciones que se ejecutarán cada vez que se acabe de nalizar el elemento, ya sea porque se haya encontrado la marca de fin ese elemento (patrón HASTA “explícito”) o orque se haya llegado al final del documento activo (patrón HASTA “implícito”). Dichas acciones han de enumerarse ntre los símbolos << y >>.

EXTL proporciona una serie de acciones útiles que son detalladas en la sección 5.4.1. Dentro de estas, son de articular importancia las acciones de navegación ‘GOROUTE’ y ‘ADDROUTE’, que son la base para que DEXTL pueda estionar dinámicamente secuencias de navegación. Este aspecto es tratado con detalle en la sección 5.4.2.

.4.1 Acciones existentes

EXTL proporciona una serie de acciones útiles. En esta sección se detalla su funcionamiento:

• REPLACE. Esta acción permite reemplazar una cadena de caracteres por otra dentro del contenido de una variable del contexto de navegación. Sus parámetros son:

o FIELD: Nombre de la variable del contexto sobre la que se ejecuta la acción. Si no se proporciona, la acción no hace nada.

o STRA: cadena a reemplazar. o STRB: cadena a insertar. NOTA: Existen tres cadenas que deben representarse de forma especial:

La cadena compuesta por un único espacio en blanco. Se especifica como “&nbsp”. La cadena vacía. Se especifica como “&empty”. La cadena “\”. Se especifia como “&dquo”.

Ejemplo: Sustituir en el valor actual de atributo PRICE la cadena “$” por la cadena “ DOLLARS”:

REPLACE(FIELD=”PRICE”, STRA=”$”,STRB=” DOLLARS”)

• ADDPREFIX. Esta acción permite añadir una cadena de caracteres al comienzo del valor de una variable del contexto de navegación. Sus parámetros son:

o FIELD (obligatorio). Nombre de la variable.



o PREFIX (obligatorio). Prefijo a añadir al valor de la variable. Ejemplo: Añadir la cadena “$” como prefijo del valor del atributo PRICE.

ADDPREFIX (FIELD=”PRICE”, PREFIX=”$”)

• EVALUATE. Evalua una expresión aritmética que puede involucrar a variables del contexto y asigna el

resultado en una nueva variable. Sus parámetros son: o RESULT (Obligatorio). Nombre de la variable conteniendo el resultado de la evaluación. o EXPRESSION (Obligatorio). Expresión aritmética a evaluar. Puede ser cualquier expresión

aritmética con los operadores de suma (‘+’), resta (‘-‘),multiplicación (‘*’), división (‘/’) y módulo (‘%’). Pueden utilizarse paréntesis para agrupar términos. Ejemplo: Asignar a la variable OUTPUTFIELD el resultado de sumar 5 al valor actual de la variable INPUTFIELD y multiplicarlo por 20.

o AUX (opcional). Si recibe el valor ‘false’ o no se indica el parámetro, la nueva variable se añadirá al elemento de datos que esté actualmente procesando el intérprete DEXTL y será devuelto a la aplicación (es decir, se habrá añadido un nuevo campo al elemento de datos extraído). Si recibe el valor ‘true’, la variable no será devuelta a la aplicación.

EVALUATE(RESULT=”OUTPUTFIELD”, EXPRESSION=”((@INPUTFIELD1 + 5)* 20)”, AUX=”TRUE”)

• EVALUATEPERL. Permite realizar transformaciones en el contenido de un campo mediante la ejecución de

una expresión Perl5 sobre su valor, utilizando expresiones regulares. Recibe los siguientes parámetros: o FIELD (Obligatorio). Nombre de la variable sobre la que se ejecutará la expresión. o EXPRESSION (Obligatorio). Una expresión Perl para reemplazar un patrón determinado de la

entrada utilizando una cadena de subtitución Perl especificada. El formato utilizado es el habitual en Perl5:

s/pattern/replacement/[g][i][m][o][s][x]. Encuentra las ocurrencias de la expresión regular especificada en pattern y las reemplaza utilizando la expresión de subtitución especificada en replacement. El signifcado de las opciones es:

• g. Sustituye todas las ocurrencias del patron utilizando la cadena de substitución (por defecto sólo sustituye la primera ocurrencia).

• i. La búsqueda de ocurrencias del patrón no será sensible a mayúsculas/minúsculas.

• m. Trata la entrada asumiendo que puede contener varias líneas.. • o. Si se utiliza interpolación de variables, evaluar la interpolación sólo la

primera vez. I • s. Tratar la entrada como compuesta de una sola línea. • x. Permitir sintaxis extendida.

o TARGET (Opcional). Nombre de la variable de salida. Si no se recibe, la transformación se

realizará sobre el mismo campo de entrada. o AUX (opcional). Si recibe el valor ‘false’ o no se indica el parámetro, la nueva variable se añadirá

al elemento de datos que esté actualmente procesando el intérprete DEXTL y será devuelto a la aplicación (es decir, se habrá añadido un nuevo campo al elemento de datos extraído). Si recibe el valor ‘true’, la variable no será devuelta a la aplicación.

Ejemplo: Supóngase que un programa DEXTL extrae datos de una tienda electrónica de libros. Para cada libro se extrae el valor de una serie de atributos incluyendo el nombre del autor del mismo. La tienda representa el nombre del autor siguiendo el formato “Apellido, Nombre” (e.g. “Cervantes, Miguel de”. La siguiente invovación de EVALUATEPERL cambia este formato por el de “Nombre Apellido” (e.g. “Miguel de



Cervantes”): (por claridad, se ha incluido el carácter “_” en lugar de los espacios en blanco contenidos dentro de la expresión indicada en el parámetro EXPRESSION). EVALUATEPERL (FIELD=”AUTHOR”, EXPRESSION=”s/(.*),(.*)/$2_$1”)

• FILTER. Acción que permite filtrar las t-uplas extraídas por un patrón DEXTL en función de si el valor

extraído para un campo contiene o no una determinada cadena de caracteres. Si no la contiene, la t-upla será descartada y no llegará a la aplicación. Recibe los siguientes parámetros:

o FIELD. Nombre de la variable del contexto de navegación sobre la que actua el filtro. o VALUE. Cadena que debe estar contenida en el valor actual de la variable indicada.

Ejemplo: Eliminar las t-uplas cuyo atributo TITLE no contenga la palabra ‘java’.

FILTER (FIELD=”TITLE”, VALUE=”java”) • FILTERCONTENT. Acción que permite filtrar las t-uplas extraídas por un patrón DEXTL en función de si el

valor extraído para un campo o para la página HTML apuntada por un enlace verifica o no una determinada expresión booleana de búsqueda. Si no la verifica, la t-upla será descartada y no llegará a la aplicación. Esta acción sólo está disponible en caso de que Denodo Aracne [ARAC] esté instalado en la misma ruta (DENODO_HOME) que ITPilot. Recibe los siguientes parámetros:

o FIELD (Opcional) . Nombre de la variable sobre la que aplicar el filtro booleano. o LINK (Opcional). Enlace al documento HTML sobre el que aplicar el filtro booleano. (NOTA: Al menos uno de los dos campos anteriores (CAMPO o LINK) debe aparecer). o EXPRESSION (Opcional). Filtro booleano que debe verificar la variable y/o el documento

apuntado por el parámetro LINK. Si no se recibe este parámetro, la accion no hace nada y la t-upla no será eliminada. El formato a utilizar para construir las expresiones puede consultarse en [ARAC].

o PROXYCONF. Necesario si se accede a Internet a través de un Proxy. Si no se requiere la utilización de login, password y realm, aún así han de rellenarse (e.g. test|test|test). El formato es: "host|port|login|password|realm"

host - IP del proxy port - Puerto del proxy login - Identificador de un usuario del proxy (sólo si requiere autenticación) password - Contraseña de un usuario del proxy (sólo si requiere autenticación). realm – Dominio del Proxy.

Ejemplo: Eliminar las t-uplas cuyo atributo “SUMMARY” no contenga la palabras ‘‘xml’ además de, o bien la palabra ‘java’ o bien la palabra ‘c++’. Nótese que las apariciones de las comillas dobles dentro del parámetro Expresión han tenido que ser escapadas con el carácter ‘\’.

FILTERCONTENT(FIELD=”SUMMARY”,EXPRESSION=”(\“java\” || \”c++\” ) && \”xml\””)

• STORECONTENT. Esta acción permite descargar a un fichero el contenido HTML de una determinada URL.

Sus parámetros son: o LINK (Obligatorio) = URL del documento a bajar. o BASEPATH (Obligatorio) = directorio raiz donde se guardará el documento bajado. o SAVEPATH (Opcional) = campo donde se devuelve al contexto la ruta al documento guardado. o PROXYCONF (Opcional) = necesario si se accede a Internet a través de un Proxy. El formato es:

"host|port|login|password|realm" host - IP del proxy port - Puerto del proxy login - Identificador de un usuario del proxy (sólo si requiere autenticación) password - Contraseña de un usuario del proxy (sólo si requiere autenticación). realm – Dominio del Proxy.



Ejemplo: Guardar el documento HTML apuntado por la URL contenida en la variable REF en la ruta “/export/home/user/docs”.

STORECONTENT (LINK=”@REF”, BASEPATH=”/export/home/user/docs”)

• SETFIELD añade una nueva variable al contexto de navegación actual del intérprete DEXTL. Puede recibir

tres parámetros:

o FIELD (obligatorio). Nombre de la nueva variable. o VALUE (obligatorio). Valor de la nueva variable. o AUX (opcional). Si recibe el valor ‘false’ o no se indica el parámetro, la nueva variable se añadirá


Ejemplo: Añadir un nuevo campo llamado CURRENCY con valor “DOLLAR” al elemento de datos extraído mediante el patrón DEXTL en el que se encuentre la invocación a la acción:

SETFIELD (FIELD=”CURRENCY”, VALUE=”DOLLAR”, AUX=”true”)

• COPYFIELD. Copia el valor de una variable del contexto de navegación en otra. Recibe los siguientes parámetros:

o SOURCE (obligatorio). Nombre de la variable origen. o TARGET (obligatorio). Nombre de la variable destino. o AUX (opcional). Si recibe el valor ‘false’ o no se indica el parámetro, la nueva variable se añadirá


Ejemplo: Copiar el valor de la variable EXPRRESULT en el atributo OUTPUTFIELD, haciéndolo además accesible a la aplicación.

COPYFIELD (SOURCE=”EXPRRESULT”, TARGET=”OUTPUTFIELD”, AUX=“true”)

• GOROUTE, ADDROUTE. El funcionamiento de estas acciones es detallado en la sección 5.4.2.

5.4.2 Acciones de Navegación (GOROUTE, ADDROUTE, RETURNROUTE)

GOROUTE: se emplea para provocar un salto hacia otro documento y continuar analizando ese documento. Tiene dos parámetros:

o METHOD = “GET” | “POST”.

o URLPATTERN = Patrón de acceso.

Esta acción se utiliza para seguir enlaces.

ADDROUTE: empleada para añadir una ruta al principio de la secuencia de rutas que quedan por analizar. Se puede utilizar esta acción para coger los resultados cuando vienen en varias páginas. Los parámetros que recibe son:





o TIMES = Número total de veces que se puede ejecuta la acción (número de páginas de resultados, sin contar la primera que se quieren analizar). Es opcional y si no se especifica nada no hay límite para las veces que se puede ejecutar.

RETURNROUTE: esta acción sirve para acceder a la URL o secuencia indicada en el parámetro URLPATTERN en el momento en que se ejecuta la acción. Es útil cuando después de acceder a una página de detalle y analizarla, hay que ejecutar una secuencia diferente a "goback(1);" (esta es la que se ejecuta por defecto) para devolver el navegador a la página donde se estaba analizando el nivel padre.



Esta funcionalidad queda como obsoleta, ya que el nuevo enfoque de ITPilot 4.0 permite describir esta funcionalidad mediante la utilización de componentes de Expresión y de Construcción de Registros.

5.5 CONTEXTOS DE NAVEGACIÓN

A lo largo del proceso de extracción de t-uplas realizado por el programa DEXTL, a menudo es conveniente disponer de un repositorio donde el programa DEXTL pueda almacenar valores que pueden serle útiles en etapas posteriores del análisis. Esto se permite realizar a través de los denominados contextos de navegación. Un contexto de navegación consiste básicamente en una lista de pares campos-valor. Los pares campo-valor del contexto pueden provenir de:

• La aplicación usuaria de Denodo ITPilot. Por ejemplo si una aplicación está siendo utilizada para buscar libros por Internet y el usuario de la misma ha decidido buscar libros que contengan la palabra ‘java’, quizás la aplicación quiera incluir en el contexto un par TITULO=’java’, de manera que posteriormente ese valor pueda ser utilizado dinámicamente para rellenar automáticamente un formulario y realizar una búsqueda por ‘java’ en una fuente web.

• Valores extraídos de los documentos recorridos durante el proceso de análisis. Cada concordancia con un patrón en alguno de los documentos recorridos produce que se añada una entrada al contexto para cada atributo de la t-upla que se ha “reconocido”, tomando el nombre del atributo y el valor que le ha sido asignado en la t-upla extraída. Si se extrajese más de una t-upla de la relación durante la navegación por la secuencia (el caso más habitual), los pares campo-valor disponibles en el contexto serán los correspondientes a la última t-upla extraída. Además cada relación tendrá accesible en el contexto la última t-upla encontrada de todas sus relaciones padre.

Una vez introducidos en él, los valores del contexto pueden ser accedidos tanto desde las especificaciones de extracción como desde las especificaciones de secuencias de navegación (explicadas en [NSEQL]). En las especificaciones de extracción, pueden utilizarse de las siguientes maneras:

• Como un separador del tipo cadena de caracteres. Esto permite que dichos separadores puedan ser obtenidos dinámicamente en una especificación.


Anexo A: Funcion

Ejemplo: Dada una fuente web que contiene t-uplas para la relación PAIS(NOMBRE, NUMERO_HABITANTES, EXTENSION_EN_KMS). Supongamos que para una aplicación determinada, se desea utilizar esta fuente de manera que consultándola por el nombre del país, devuelva los datos del mismo.

Sin embargo, la interfaz para obtener los datos NO consiste en un formulario que permita al usuario introducir el nombre del país y devuelva la información sobre el mismo, sino que se basa en una página que lista todos los países con un enlace a cada uno de ellos. Pulsando en el enlace correspondiente al país deseado, se accede a una página de detalle donde se encuentran los datos deseados.

El problema de construir un programa que dado el nombre del país (supongámoslo introducido en el contexto con el nombre ‘PAIS’), obtenga la URL de la página que contiene sus datos, podría tratarse con la siguiente especificación:

L‘

• C

• C

ANCHOR (:URLPAGINAPAIS=URL) "@PAIS" ENDANCHOR

alidad DEXTL obsoleta 36

Figura 30 Patrón

a URL a la página conteniendo los datos del país, quedaría almacenada en el contexto con el nombre URLPAGINAPAIS’.

omo un valor para atributos con valores fijos o por defecto.

omo un valor o un parámetro de una función para los atributos ligados a marcas (p.e. ANCHOR(URL=^CompleteURL(href,@URLBASE)):="<a" [^>]* ">").


Bibliografía 37

BIBLIOGRAFÍA

[ARAC] Guía del Administrador de Denodo Aracne. Denodo Technologies, 2007.

[DESAR] Guía del Desarrollador de ITPilot. Denodo Technologies, 2007.

[FLEX] JFLEX: The Fast Scanner Generator for Java. http://www.jflex.de/.

[GENER] Manual del Entorno de Ejecución de ITPilot. Denodo Technologies, 2007.

[NSEQL] Manual de NESQL. Denodo Technologies, 2007.

DENODO ITPILOT 4.0 MANUAL DEXTLhelp.denodo.com/platform-docs/4.0/DenodoITPilot.ManualDEXTL.pdf ·...

Documents

Transcript of DENODO ITPILOT 4.0 MANUAL DEXTLhelp.denodo.com/platform-docs/4.0/DenodoITPilot.ManualDEXTL.pdf ·...