Karine Gomes Chaves. Belo Horizonte. Dissertação apresentada ao Curso de Pós- de Minas Gerais, como requisito parcial

Transcrição

1 Karine Gomes Chaves Realimentação de Exemplos na Extração de Dados Semi-Estruturados Dissertação apresentada ao Curso de Pós- Graduação em Ciência da Computação do Instituto de Ciências Exatas da Universidade Federal de Minas Gerais, como requisito parcial para a obtenção do grau de Mestre em Ciência da Computação. Belo Horizonte 06 de julho de 2000

2

3 Resumo Este trabalho apresenta uma extensão à DEByE - Data Extraction By Example - que é uma ferramenta para extração de dados semi-estruturados baseada em exemplos. Esta ferramenta consiste atualmente de três módulos, uma Interface Gráfica que auxilia o usuário na especificação dos objetos de exemplo existentes nas páginas da Web, um módulo Extrator que realiza a extração dos dados de interesse para o usuário e um módulo Visualizador que apresenta para o usuário o resultado da extração e permite que o mesmo melhore esse resultado através da utilização do processo de realimentação de exemplos. Os exemplos fornecidos pelo usuário são posteriormente usados para gerar padrões de extração que serão utilizados pelo Extrator para recuperar outros objetos de páginas da Web, com o mesmo contexto e estrutura da página de onde foi fornecido o exemplo. Experimentos realizados anteriormente com a ferramenta indicaram que se o usuário pudesse retornar ao exemplo fornecido e modificá-lo, o resultado da extração poderia ser melhorado. Baseado nisso, foi incorporado à ferramenta facilidades de realimentação dos exemplos especificados.

4

5 Abstract This work presents an extension to a tool, called DEByE - Data Extraction By Example, for extracting semi-structured data through examples provided by the user. Currently, this tool is composed of three modules, a Graphic User Interface (DEByE-GUI) that assists the user with the specification of the example objects present in the Web pages, an Extractor responsible to perform the extraction of the objects that the user is interested in, and a Visualizer module that shows the extraction results to the user and allows him/her to improve it by giving new example objects through an example feedback process. The example objects specified by the user are then used to generate object extraction patterns. These patterns are used by the extractor to extract other objects from similar Web pages. Experiments carried out with the DEByE tool showed that if the user can modify the example objects that had already been specified, the extraction result may be improved. Based on this, an example feedback facility was added to the DEByE tool.

6

7 Agradecimentos Gostaria de agradecer em primeiro lugar a Deus por ter me iluminado ao longo desses anos, aos meus pais e ao meu querido Tio Paulo pelo apoio e confiança em mim depositados. Gostaria de agradecer a todos os amigos do laboratório de banco de dados pelo ambiente descontraído e familiar que muito me ajudou a superar os momentos difíceis desta jornada. Em especial, ao Paulo Golgher e Altigran Silva que foram dois companheiros e amigos indispensáveis na realização deste trabalho. Gostaria de agradecer ao Rodrigo Antunes por ter me incentivado a fazer o curso de mestrado e ao Cristiano Ligieri pela amizade e pelas longas noites de estudo nos laboratórios do DCC. Gostaria de agradecer também ao Marden Neubert pela paciência, compreensão e carinho ao longo desses anos. Agradecimentos especiais ao meu orientador, Alberto Laender, por ter me conduzido tão bem ao longo do mestrado e da dissertação e por ter se privado de alguns fins-de-semana com a família para me ajudar na conclusão deste trabalho. vii

8 viii

9 Sumário 1 Introdução Motivação Objetivos Visão Geral da Ferramenta DEByE Trabalhos Relacionados Organização da Dissertação Extração de Dados Semi-Estruturados Baseada em Exemplos Caracterização dos Dados Semi-Estruturados Modelo de Objetos DEByE-OM Armazenamento e Manipulação de Dados no Ambiente DEByE Extração de Dados Abordagem Baseada em Exemplos Especificação dos Objetos de Exemplo Padrão para Extração de Objetos Estratégia de Extração Adotada pela DEByE Realimentação de Exemplos na DEByE Visão Geral da DEByE Especificação de Exemplos Geração dos Padrões para Extração Extração de Dados da Página de Amostra Visualização do Resultado da Extração Realimentação de Exemplos na Página de Amostra Realimentação de Exemplos em Outras Páginas do Site Alguns Aspectos da Implementação Experimentos Realizados Introdução Objetivos do Experimento ix

10 4.3 Descrição do Experimento Fontes de Dados Utilizadas no Experimento Resultados Obtidos Conclusões Gerais do Experimento Conclusões e Trabalhos Futuros Revisão do Trabalho Comparação com Outras Abordagens Trabalhos Futuros x

11 Lista de Figuras 1.1 Visão geral da arquitetura da ferramenta DEByE Extrato de uma página do site CD Studio Estrutura hierárquica de um dos objetos implícitos da Figura Tabela aninhada representando três instâncias de de acordo com (2.1) Arquivo DTOR contendo instâncias de tipos de objetos complexos Arquivo DTOR contendo instâncias de tipos de objetos complexos Extrato de uma página do site CD Studio Exemplo de um contexto AVP Exemplos de padrões AVP Padrões para extração gerados para os objetos de exemplo da Figura Arquivo DTOR contendo dois objetos complexos CD Studio como exemplo Padrões de extração gerados para os objetos de exemplo da Figura Execução do algoritmo bottom-up Visão geral do algoritmo bottom-up Tela de uma sessão típica de extração através da ferramenta DEByE Tela capturada durante a especificação de exemplos através da ferramenta DEByE Operações para estruturação de tabelas Exemplo de criação de uma tabela aninhada através da operação group Resultado da extração referente aos objetos de exemplo da Figura Janela utilizada na realimentação dos exemplos Tela capturada durante uma sessão de realimentação de exemplos através da DEByE Resultado da extração referente aos objetos de exemplo da Figura Resultado da extração referente ao padrão salvo para a FDW CD Studio Extrato das páginas de amostra da e M % 4.2 Extrato das páginas de amostra dos sites "!$#% &'(*) +,, -.0/1'(324&'65, e 798:<;= Extratos das páginas de amostra dos sites?>a@=+-b#"c:ed3f8, GH2IJLK N('&O e?>a@=+-pq=?> xi

12 xii

13 Lista de Tabelas 4.1 Realimentação de exemplos na página de amostra Objetos recuperados usando um padrão de extração previamente salvo Realimentação de exemplos em outras páginas das FDW Resumo geral da extração de dados semi-estruturados nas FDW em questão.. 46 xv

14 xvi

15 Capítulo 1 Introdução 1.1 Motivação O crescimento das bibliotecas digitais modernas e a popularização da Internet, em especial da World Wide Web (Web), fizeram com que um grande volume de informação se tornasse disponível para inúmeros usuários. Esses usuários, por sua vez, têm tido um interesse cada vez maior em acessar tais informações. Devido a isto, surgiu a necessidade de se desenvolver ferramentas eficientes para gerenciar, recuperar e filtrar as informações da Web. Além da Web, atualmente existem outros meios de acesso on-line para disseminação dessas informações, tais como artigos de newsgroups, mensagens de correio eletrônico, catálogos eletrônicos, etc. Entretanto, encontrar uma informação desejada no vasto repositório de dados da Web não é uma tarefa trivial. É sabido, inclusive, que muitos usuários consideram difícil e muitas vezes impossível encontrar uma informação de seu interesse. As razões para isso são muitas: os documentos são escritos em linguagem natural que são complexas e semanticamente ambíguas; os usuários não estão bem preparados para formular consultas que reflitam diretamente as suas necessidades; os usuários podem estar interessados em dados estruturados que existem em muitas páginas da Web mas que não são reconhecidas por interfaces tradicionais de busca. Para ilustrar melhor esse problema, considere que um usuário que acessa um Web site 1 de venda de discos deseja obter a seguinte informação: Quais são os discos do Caetano Veloso com preços abaixo de R$ 30,00?. Obter uma resposta a esta consulta, utilizando as interfaces tradicionais de busca na Web, pode exigir que o usuário navegue exaustivamente por várias páginas do site. Porém, para evitar esse problema, pode-se extrair automaticamente os dados da página da Web, armazená-los em seguida em um banco de dados relacional, por exemplo, e então realizar as consultas desejadas. Isso permitiria que se encontrasse facilmente a resposta à consulta anterior. 1 Por falta de um termo melhor em português, será usado nesta dissertação o termo Web site para se referir a sítios da Web. 1

16 2 Introdução Os sites e serviços da Web que possuem dados de interesse para extração e provoamento de bancos de dados apresentam duas características importantes: são ricos em dados e possuem uma abrangência semâncita limitada, ou seja, os dados disponíveis versam sobre assuntos bem definidos [23]. Nesta categoria estão Web sites de livrarias eletrônicas e referências bibliográficas, catálogos eletrônicos, arquivos Bibtex, s sobre ofertas de produtos, etc. Fontes de dados desse tipo podem ser consideradas como repositórios de dados por possuírem dados implícitos que podem ser identificados, extraídos e manipulados de maneira independente. Neste trabalho é usado o termo FDW (Fontes de Dados da Web) para referenciar tais sites. Em geral, extrair dados disponíveis dessas fontes da Web não é um problema simples. Esses dados normalmente não estão estruturados da maneira como ocorre, por exemplo, em bancos de dados tradicionais [21]. Ao contrário, cada fonte de dados (páginas de dados, artigos de newsgroups, mensagens de correio eletrônico, etc.) apresenta características bastante particulares no que diz respeito a formas de acesso e organização dos dados nelas contido. Mesmo quando os dados disponíveis estão estruturados, essa estrutura é muito menos regular do que aquela encontrada em bancos de dados tradicionais. Além disso, esta estrutura está apenas implicitamente definida. Na literatura recente, dados desse tipo são usualmente chamados semiestruturados [2, 3, 11]. Diversos trabalhos [4, 5, 6, 7, 23, 24, 27, 28, 51] têm sido desenvolvidos propondo soluções distintas para o problema de extração e manipulação de dados semi-estruturados disponíveis na Web. Esses trabalhos baseiam-se em abordagens que variam, desde aquelas em que o usuário especifica manualmente o formato dos dados a serem extraídos [6, 28], até aquelas em que a extração ocorre de maneira semi-automática [5, 23, 7]. Entretanto, na maioria dessas abordagens, o processo de extração demanda dos usuários o conhecimento prévio de aspectos da formatação e organização ímplicita dos dados nas páginas onde estes ocorrem. Assim, é grande atualmente a demanda por métodos e técnicas de extração de dados adequados aos usuários da Web. Este trabalho está inserido no contexto do ambiente DEByE (Data Extraction By Example) que é fundamentado em uma abordagem baseada em exemplos para tratamento de dados semiestruturados oriundos da Web. O ambiente possui uma série de componentes, ainda em estudo, desenvolvidos em torno da ferramenta DEByE, usada para extração de dados semi-estruturados de páginas da Web [34]. Esses componentes provêm mencanismos para realizar consultas sobre os dados extraídos, armazenar esses dados em bancos de dados relacionais, além de permitir a especificação de agentes de coleta automática de páginas de onde os dados serão extraídos [25]. No ambiente DEByE, a extração dos dados baseia-se na percepção do usuário para reconhecimento da estrutura ímplicita dos dados a serem extraídos. Usando uma interface gráfica, o usuário constrói objetos de exemplo a partir de dados retirados de uma página de amostra pertencente a uma determinada fonte de dados. A partir desses objetos de exemplo, são gerados padrões de extração que alimentam um módulo extrator para extrair outros objetos, cuja

17 1.2 Objetivos 3 estrutura seja similiar aos objetos de exemplo, presente em outras páginas da mesma fonte de dados. 1.2 Objetivos Experimentos realizados com a ferramenta DEByE [44] indicaram que alguns erros cometidos pelo usuário ao especificar os exemplos poderiam ter sido prontamente detectados se a ferramenta permitisse que o usuário visualizasse imediatamente o resultado da extração e realimentasse os seus exemplos. De acordo com esses experimentos, pôde-se perceber também que o resultado da extração melhora consideravelmente à medida que se aumenta o número de exemplos fornecidos. Devido a isto, surgiu a idéia de o usuário poder retornar ao exemplo dado, modificá-lo e submetê-lo novamente de formar a melhorar esse resultado. Dessa forma, a ferramenta poderia reagir à interação com o usuário, permitindo que o mesmo avaliasse a correção e eficácia dos exemplos especificados. O objetivo desta dissertação foi desenvolver um módulo interativo para visualização dos dados extraídos que permita ao usuário realimentar o processo de extração e estender esse mesmo processo a várias páginas de um determinado site e não só àquela que foi utilizada na especificação dos exemplos. A grande vantagem dessa interface de visualização é que através dela o usuário pode analisar o que foi extraído da Web e, se perceber que os objetos extraídos não estão de acordo com a sua especificação ou não foram totalmente extraídos, poderá modificar o exemplo fornecido ou criar novos exemplos. Esse ciclo pode perdurar até que o usuário se satisfaça com o resultado obtido. Assim ele poderá utilizar o extrator construído para a página de amostra em outras de igual contexto e estrutura. 1.3 Visão Geral da Ferramenta DEByE O ambiente DEByE (Data Extraction By Example) para tratamento de dados semi-estruturados é formado por diversos componentes integrados. Esses componentes realizam a coleta automática de documentos da Web que contêm dados de interesse para o usuário, a extração de dados contidos nesses documentos e o armazenamento desses dados em repositórios textuais ou em um banco de dados relacional. Um componente adicional provê ainda uma interface gráfica para consulta aos dados extraídos. Esta dissertação aborda a ferramenta DEByE (Figura 1.1), que é o componente responsável pelo processo de extração de dados. Os outros componentes não fazem parte do escopo deste trabalho. A extração de dados semi-estruturados envolve duas fases. A primeira fase consiste na especificação de objetos de exemplo relevantes para a extração. Na segunda fase, é feita a extração de objetos da fonte de dados com base nas diretivas fornecidas pela fase anterior. A especificação de exemplos é feita pelo usuário através de uma interface gráfica (Graphic User

18 4 Introdução Interface - GUI) [49] a partir de objetos reconhecidos em uma página de amostra cuja estrutura é representada por meio de uma tabela aninhada. Esses exemplos são utilizados para gerar padrões de extração que são utilizados pelo módulo Extrator [44, 45] para a extração de novos objetos dessa página. Página Web de Amostra Conjunto de Exemplos Página Web de Interesse DEByE Interface Gráfica Padrões de Objetos de Extração Extrator Usuário Conjunto de Exemplos Realimentados Visualizador Objetos Extraídos Resultado da Extração Usuário Figura 1.1: Visão geral da arquitetura da ferramenta DEByE Os objetos extraídos pelo módulo Extrator são armazenados em arquivos-texto, de acordo com um formato baseado na notação XML (extended Markup Language) [10], chamado DTORF (DEByE Textual Object Repository Format). O DTORF constitui uma implementação do modelo de objetos usado para representar dados semi-estruturados denominado DEByE-OM (DEByE Object Model). Os dados armazenados no formato DTORF são, posteriormente, manipulados por métodos disponíveis em bibliotecas de manipulação de XML, como DOM (Document Object Model) [60, 53], e apresentados ao usuário pelo módulo Visualizador. Através deste módulo, o usuário pode analisar os objetos que foram recuperados e realimentar o processo de extração especificando novos exemplos até que considere satisfatório o resultado da extração. Quando isso acontecer, o usuário poderá salvar o padrão de extração gerado para essa página de amostra, para ser então reutilizado pelo módulo Extrator na extração automática de dados de outras páginas da Web de igual contexto e estrutura. 1.4 Trabalhos Relacionados A área de pesquisa relacionada com modelagem, extração e manipulação de dados semi-estruturados, notadamente aqueles disponíveis na Web, tem se desenvolvido rapidamente. Uma visão geral dos problemas de tratamento desses dados pode ser encontrada em [3, 11, 24]. Com

19 1.4 Trabalhos Relacionados 5 relação aos trabalhos específicos sobre extração de dados, as principais abordagens propostas na literatura são o uso de wrappers, extração baseada em Processamento de Linguagem Natural e uma abordagem baseada em ontologias 2. Existe ainda uma outra linha de estudos, como é o caso da abordagem DEByE (Data Extraction By Example) na qual este trabalho é baseado, onde a extração dos dados semi-estruturados é guiada por diretivas fornecidas pelo usuário. Muitos modelos de dados têm sido propostos para representar dados semi-estruturados [12, 13, 41]. Esses modelos utilizam geralmente grafos dirigidos para representar os dados e são fracamente tipados, não impondo restrições sobre os tipos de dados. Na abordagem DEByE, é adotado um modelo de dados simples onde os objetos complexos são representados como tabelas aninhadas. No Capítulo 2, a Seção 2.2 descreve com mais detalhe esse modelo. Uma das técnicas mais usadas para extração de dados de fontes da Web é o uso de wrappers [59]. Originalmente, os wrappers eram escritos manualmente para fontes de dados específicas [8, 28]. Porém, devido às limitações dessa técnica, esforços têm sido empregados para automatizar o processo de geração de wrappers [7, 29, 38]. Inclusive, alguns trabalhos recorrem ao uso de autômatos para induzir a geração automática ou semi-automática de wrappers [20, 30, 32, 38, 39]. Apesar dos wrappers constituirem uma técnica eficiente para extrair dados de fontes da Web, eles requerem um conhecimento prévio da estrutura das páginas e são sensíveis a mudanças nessa estrutura. Devido a esses problemas, acredita-se que a abordagem DEByE pode ser útil ao usuário auxiliando-o com o processo de geração de wrappers, visto que nessa abordagem não é necessário um conhecimento prévio das páginas da Web e qualquer mudança na estrutura dessas páginas pode ser facilmente contornado com o processo de realimentação dos exemplos. As técnicas para extração de dados semi-estruturados baseadas em Processamento de Linguagem Natural, também chamadas de NLP (Natural Language Processing), representam uma possível solução para o problema de extração de dados de fontes com pequeno grau de estruturação, chegando até mesmo ao processamento de textos sem estrutura alguma. Essas técninas de NLP baseiam-se na estrutura sintática da linguagem e permitem determinar um contexto coerente para as informações extraídas. O sistema descrito em [52] é um exemplo de uma ferramenta de extração de dados que utiliza essa técnica. Uma outra abordagem para extração de dados faz uso de modelos semânticos baseados em ontologias. A idéia é que, com base em um determinado modelo, seja gerado um esquema sobre um domínio de interesse e que os dados sejam então estruturados de acordo com esse esquema. Embley et al. [22, 23] usam um modelo semântico de dados que provê uma ontologia descrevendo a visão dos dados desejada sobre um domínio de interesse. Dessa forma, uma fonte é descrita segundo uma ontologia e com base nela a extração é feita, independente da estrutura associada à fonte. Nota-se que, apesar dessa abordagem também requerer que o 2 Ontologia é um ramo da filosofia que tenta modelar os objetos de maneira muito próxima à sua existência no mundo real.

20 6 Introdução usuário determine a descrição conceitual dos dados a serem extraídos, ela difere da abordagem DEByE no que diz respeito à estratégia de extração adotada. Enquanto a DEByE está interessada no contexto textual em torno dos dados de interesse na página, a abordagem ontológica está interessada principalmente no conteúdo das páginas de acordo com o que foi especificado antecipadamente pela ontologia. Além de todos os trabalhos já mencionados, existem ainda aqueles onde a extração dos dados semi-estruturados é direcionada pelo usuário. Dentre esses, pode-se citar as ferramentas NoDoSe [5], XWRAP [35], W4F [46, 47, 48] e a DEByE [34]. No decorrer desta dissertação, a abordagem DEByE será descrita em detalhes, bem como o funcionamento da ferramenta em relação ao processo de extração dos dados e realimentação dos exemplos fornecidos pelo usuário. O NoDoSe (Northwestern Document Structure Extractor), apresentado por Adelberg [5], é uma ferramenta interativa para estruturação semi-automática de dados semi-estruturados de documentos. É importante notar que tanto a estruturação, quanto a extração de dados, são feitas de forma semi-automática. Dessa maneira, o usuário intervém tanto no processo de estruturação da fonte, quanto no processo de extração propriamente dito. Essa ferramenta possui uma interface gráfica que o usuário utiliza para decompor um dado documento (por exemplo, uma página da Web) em uma hierarquia que descreve a sua estrutura. Depois, outros documentos do mesmo tipo são passados para a ferramenta e analisados automaticamente. Se um ajuste for necessário, o usuário poderá inspecionar o resultado da extração através da interface da ferramenta, modificar a hierarquia que descreve os documentos e usá-la novamente para analisar as páginas. O processo é finalizado quando todos os documentos forem analisados com sucesso. Sendo assim, essa é uma técnica baseada em tentativas e erros, o que significa que o usuário participa de todo o processo. Uma diferença marcante entre a ferramenta DEByE e a NoDoSe é a forma como os exemplos são fornecidos pelo usuário para gerar os padrões de extração. Enquanto no NoDoSe o usuário decompõe um documento delimitando regiões no corpo inteiro do mesmo, na DEByE o usuário marca valores atômicos que ele organiza de acordo com sua percepção em relação a estrutura implícita dos objetos a serem extraídos das páginas. Assim, as características específicas de formatação dessas páginas são completamente transparentes para o usuário. Uma outra abordagem interessante para extração de dados da Web dirigidos pelo usuário é o XWRAP [35]. Nessa ferramenta, é apresentado ao usuário a sintaxe de uma árvore que descreve a estrutura HTML (HiperText Markup Language) [43] da página que ele deseja realizar a extração. Os nodos dessa árvore correspondem a tags HTML (por exemplo, R TABLES, R TRS, etc.). Através de navegações nessa árvore, o usuário seleciona as porções da página que ele está interessado em extrair e para, cada porção, a ferramenta aplica um conjunto de regras de extração pré-definidas. Existem regras para tabelas, listas, etc. Os dados extraídos são então formatados em XML. Percebe-se que a principal desvantagem dessa ferramenta é o uso explícito da sintaxe e estrutura do código HTML pelo usuário final. Essa é uma diferença

21 1.5 Organização da Dissertação 7 considerável dessa ferramenta se comparada com a DEByE, visto que nesta as características de formatação das páginas Web são transparentes para o usuário. A W4F (WysiWyg Web Wrapper Factory) [46, 47, 48] é uma outra ferramenta para geração de wrappers para fontes de dados da Web. Esta consiste de três componentes básicos que são uma linguagem de recuperação para identificar as fontes da Web, uma linguagem declarativa para expressar as regras de extração e uma interface de mapeamento para transformar as informações extraídas em uma estrutura de dados definida pelo usuário. Essa ferramenta funciona da seguinte forma. Um documento HTML é primeiramente obtido da Web de acordo com uma ou mais regras de recuperação. Uma vez recuperados, esses documentos são usados para alimentar um parser que constrói uma árvore de acordo com o formato DOM [53, 60]. Regras de extração são então aplicadas à árvore DOM construída e as informações extraídas são armazenadas em um formado NSL (Nested String List), específico da ferramenta. Finalmente, essas estruturas NSL são exportadas para uma aplicação de nível mais alto, de acordo com as regras de mapeamento. Todas essas regras que determinam o processo de geração dos wrappers são construídas pelo usuário com a ajuda da ferramenta. Uma desvantagem perceptível da W4F, é que ela depende da habilidade do usuário em saber escrever as regras de geração dos wrappers, pois caso o mesmo não saiba, a ferramenta não consegue extrair as informações das fontes da Web de forma adequada. A abordagem DEByE, ao contrário dessas mencionadas anteriormente, é baseada em duas considerações fundamentais: um pequeno conjunto de objetos de exemplo (fornecidos pelo usuário) pode ser usado para extrair efetivamente milhares de objetos de várias fontes de dados da Web e a especificação desses objetos pode ser feita sem dificuldades usando a metáfora de tabelas aninhadas adotada pela DEByE. O usuário ou o projetista de banco de dados que usar essa ferramenta não precisa se preocupar com detalhes de como representar a estrutura dos dados a serem extraídos ou como realizar a extração desses dados, podendo o mesmo se concentrar em o que extrair das páginas de seu interesse. 1.5 Organização da Dissertação Esta dissertação está organizada da seguinte forma. O Capítulo 2 discute o conceito de dados semi-estruturados, apresenta o modelo de objetos DEByE-OM no qual a ferramenta está baseada e descreve também o processo de extração de dados semi-estruturados adotado pela abordagem DEByE. No Capítulo 3 encontra-se uma visão geral do funcionamento da ferramenta e a descrição detalhada de todo o processo de realimentação de exemplos. Detalhes da implementação realizada neste trabalho também são discutidos nesse capítulo. O Capítulo 4 descreve os experimentos realizados com o objetivo de validar o processo de extração e como a realimentação pode auxiliar o módulo Extractor a recuperar um maior

22 8 Introdução número de objetos, bem como discute os resultados obtidos. Finalmente, no Capítulo 5 são apresentadas as conclusões deste trabalho e as contribuições proporcionadas pela abordagem adotada. São propostos também trabalhos futuros e melhorias ao sistema implementado.

23 T T T T T Capítulo 2 Extração de Dados Semi-Estruturados Baseada em Exemplos 2.1 Caracterização dos Dados Semi-Estruturados Um conjunto de dados é semi-estruturado, segundo Abiteboul [2], se possui as seguintes características: a estrutura é irregular, isto é, os dados são heterogêneos, apesar de possuírem alguma estrutura, podendo tanto apresentar alguns elementos incompletos, quanto apresentar alguns componentes extras. a estrutura é implícita, ou seja, apesar de a estrutura existir, ela não é explicitamente definida (documentos escritos utilizando alguma linguagem de marcação, tais como aquelas derivadas de SGML (Standard Generalized Markup Language) [19], constituem bons exemplos deste caso). a estrutura é parcial, caso de fontes que contêm elementos não estruturados, tais como vídeo, áudio, etc. a estrutura é apenas indicativa, isto é, os dados não seguem necessariamente a organização imposta pela estrutura, ao contrário do que ocorre com os bancos de dados tradicionais. a noção de esquema, mesmo existindo, pode exigir uma descrição muito extensa e geralmente está em constante mutação, não podendo servir como referência para descrever a estrutura dos dados. Em muitos casos práticos, essas características estão presentes em fontes de dados da Web cujo conteúdo é de interesse para várias aplicações. Embley et al. [22, 23] classificam essas 9

24 10 Extração de Dados Semi-Estruturados Baseada em Exemplos fontes de dados semi-estruturados como ricas em dados (data rich), se elas possuem um grande número de constantes identificáveis como dados potencialmente relevantes para extração, e como de abrangḙncia semˆantica limitada (narrow in ontological breadth), se o seu domínio de aplicação puder ser descrito segundo um modelo de ontologia simples, isto é, com um pequeno número de objetos e de relacionamentos entre eles. A Figura 2.1 apresenta um extrato de uma página de uma dessas fontes de dados da Web, o site da loja virtual de venda de discos CD Studio [16]. Como se pode observar, esta página contém dados sobre discos da música popular brasileira organizados por artistas, sendo que, para cada artista, identifica-se claramente o seu nome e a lista de seus discos, juntamente com seus nomes e preços, disponíveis na loja. Figura 2.1: Extrato de uma página do site CD Studio Apesar de sua importância para diversos tipos de aplicação, os dados disponíveis nessas fontes de dados da Web são de difícil manipulação, o que se deve em grande parte às características mencionadas anteriormente. A seguir, será mostrado como esses dados podem ser manipulados de acordo com o modelo DEByE-OM, utilizado pela ferramenta DEByE. 2.2 Modelo de Objetos DEByE-OM No ambiente DEByE, páginas da Web são vistas como coleções de objetos complexos que possuem uma estrutura implícita. Esses objetos, por sua vez, podem ser compostos de outros objetos complexos, formando uma estrutura hierárquica de objetos. Por exemplo, no extrato da

25 2.2 Modelo de Objetos DEByE-OM 11 página do site da loja virtual CD Studio apresentado na Figura 2.1, pode-se identificar porções distintas contendo dados sobre discos de três artistas. Cada uma dessas porções de dados pode ser considerada um objeto implícito. Para cada um desses objetos, pode-se identificar um nome de artista associado a uma lista de discos. Para os discos de uma lista, encontra-se informações sobre títulos e preços. Dessa maneira, existe uma estrutura inerente a cada objeto presente na página da Figura 2.1. Os objetos implícitos nesta figura possuem uma estrutura de vários níveis e, devido a isto, são chamados objetos complexos. A Figura 2.2 representa a estrutura hierárquica inerente ao objeto correspondente ao artista Caetano Veloso. CD_Studio Artista Caetano Veloso Disco Titulo Preco (Alguem Cantando Caetano, 16,10) Figura 2.2: Estrutura hierárquica de um dos objetos implícitos da Figura 2.1 O ambiente DEByE utiliza-se do conceito de tipo de objeto para criar abstrações para conjuntos de objetos complexos que apresentam uma estrutura similar. Um objeto de um tipo específico é considerado uma instância daquele tipo. Assim, os objetos podem ser definidos a partir dos seguintes tipos de dados: atômico, lista, tupla e variante [33]. Um objeto de um tipo atˆomico (a-type) pode assumir apenas valores atômicos. Um objeto de um tipo lista (l-type) é um conjunto ordenado de objetos do mesmo tipo. Um objeto de um tipo tupla (t-type) é uma agregação de outros objetos. Objetos de um tipo variante (v-type) são objetos de qualquer tipo de uma lista de tipos chamados alternativas do tipo variante. Tipos variantes são usados para representar a natureza semi-estruturada dos dados, definindo possíveis estruturas distintas que um mesmo objeto complexo pode apresentar. A sintaxe e a semântica de cada tipo de objeto definido anteriormente são descritas detalhadamente em [33]. A seguir é apresentado um exemplo de um tipo de objeto complexo definido de acordo com a notação introduzida em [33]. Neste exemplo, um l-type foi definido sobre o t-type J Ü. O t-type J Ü X ZY é composto por um a-type V+W e por um l-type [ XJ\. A estrutura interna do t-type X+\ ^ J U_J \ por sua vez é composta de dois a-type sendo estes ] e ` W a. O l-type descrito acima pode ser utilizado para descrever a estrutura dos dados encontrados no extrato da página da Figura 2.1. b J Ü :c (V+W X ZY, b XJ\J :(] ^ J U_J,`+Wa \ )d )]d (2.1) O DEByE-OM permite que os objetos extraídos sejam representados por tabelas aninhadas. A correspondência entre tabelas aninhadas e objetos complexos permite que todo esquema de uma tabela seja representado em termos de objetos complexos. Entretanto, o contrário não é necessariamente verdadeiro [33]. Desta forma, podemos concluir que objetos complexos são

26 v v v 12 Extração de Dados Semi-Estruturados Baseada em Exemplos mais poderosos para representar objetos encontrados na Web quando comparados ao paradigma de tabelas aninhadas. Por outro lado, tabelas aninhadas caracterizam-se por serem simples, intuitivas e expressivas para representar esses objetos. Na abordagem DEByE, esse paradigma foi escolhido por facilitar a descrição da estrutura de objetos complexos identificados pelo usuário. A noção usual de tabelas aninhadas foi estendida para permitir variações na estrutura destas tabelas e, portanto, acomodar a natureza semi-estruturada dos dados encontrados na Web. Seja e : b ] :flvhgijv+k imlnlov pqrd um l-type definido sobre o t-type ]. Uma instância deste tipo pode ser vista como uma tabela cujas linhas (tuplas) são instâncias do t-type ] e cujas colunas são instâncias dos tipos Vhg^ijV+k6islnltlnijV p. Se cada componente V u é do tipo atômico, temos uma tabela relacional pura. Para representar atributos multivalorados, basta que um dos V u seja definido como uma lista sobre um tipo atômico, por exemplo, V u bv : u6d. Para o caso de tabelas aninhadas, temos que um V u qualquer pode ser definido como V u b : u :f uswri uyxisltlni u{z q}d, onde os valores destes atributos são instâncias que podem ser vistas como tabelas. A Figura 2.3 apresenta uma tabela representando instâncias extraídas da Figura 2.1. A estrutura dessa tabela corresponde ao l-type definido em (2.1). ˆ* Caetano Veloso Tom Jobim Chico Buarque ~ ( ƒ } ˆŠr s Œ( ^Ž6Šr Alguem Cantando Caetano 16,10 Caetano Canta Vol.2 10, s Œ( ^Ž6Šr A Twist if Jobim 10,40 And Friends 10,60 s Œ( Ž6Šr Almanaque 19,90 Chico Buarque 19, Figura 2.3: Tabela aninhada representando três instâncias de Ü de acordo com (2.1) Armazenamento e Manipulação de Dados no Ambiente DEByE Os componentes do ambiente DEByE manipulam representações textuais de objetos semiestruturados armazenados em arquivos chamados DTOR (DEByE Textual Object Repositories) [33]. O DTORF (DTOR Format) é portanto um formato textual para representação de obje-

27 2.2 Modelo de Objetos DEByE-OM 13 tos semi-estruturados no ambiente DEByE. Este formato constitui uma implementação XML do modelo de objetos DEByE-OM. A notação XML foi escolhida para permitir que os repositórios de dados possam ser manipulados de diversas formas utilizando ferramentas disponíveis. Assim, os dados extraídos podem ser consultados, integrados a outros dados, armazenados em bancos de dados relacionais ou republicados na Web em diferentes formas de apresentação. A sintaxe do DTORF baseia-se nos conceitos apresentados na Seção 2.2 e utiliza tags aninhadas para representar instâncias de tipos de objetos complexos. A terminologia utilizada no DTORF é a terminologia do DOM (Document Object Model) [53, 60], e utiliza conceitos como elementos, atributos, etc. A Figura 2.4 apresenta um arquivo DTOR contendo instâncias de tipos de objetos complexos encontrados na Figura 2.1. O DTORF utiliza quatro tipos de elementos: R<V ] [S para representar instâncias de objetos de um tipo atômico, R eu ]S para representar instâncias de objetos de um tipo lista, R?] `+e S para representar instâncias de objetos de um tipo tupla, e R +V 6VJ ]S para representar instâncias de objetos de um tipo variante. O tipo de um objeto é identificado pelo valor do atributo type do elemento que representa aquela instância. A tag R +VJe S é utilizada para armazenar valores de instâncias de objetos de um tipo atômico. Quando esses valores não são recuperados pelo módulo extrator, no momento em que este realiza a extração, então a tag R< +V+e h S é usada. Esta tag também pode ser usada quando não existe um determinado valor para o objeto atômico na página onde está sendo realizado o processo de extração. Por exemplo, se na loja virtual CD Studio existir o disco Frederico e Giulietta do artista Caetano Veloso, mas por ser muito recente, não se sabe ainda \ por quanto o mesmo será vendido, o objeto atômico ` W a, nesse caso, estaria sem um valor específico. Assim, a tag R VJe h S seria usada para representar a ausência de um valor para o preço desse disco. A primeira linha de todo arquivo DTORF (R?xml version = 1.0?S R?xml:stylesheet type= text/xsl href= nested.xsl?s ) é usada para indicar que o mesmo foi construído baseado no formato XML. Todo arquivo XML [10] começa com essas informações na primeira linha, que dizem respeito à versão do XML usada e como o mesmo será visualizado. No caso da ferramenta DEByE, a visualização se dá seguindo o formato de tabelas aninhadas, assim como na especificação dos exemplos, conforme será mostrado no Capítulo 3. O DTORF permite o uso de elementos de um tipo variante dentro de elementos de um tipo lista para a construção de listas heterogêneas possibilitando a representação das características semi-estruturadas dos dados armazenados.

28 14 Extração de Dados Semi-Estruturados Baseada em Exemplos š rœ} ŒŸžŽ( ˆ^ * r + 0 š rœ} Œhªjˆ* «6Œ(Ž6ŝ 6ŽŽr «6Ž O Ž œ 6 œ ˆ(Œ ^ Ž(± O6Žˆ* Ž ƒ[ œ ˆ(Œ š²}³ }µ ~ š ( ^ µ «6Ž m~ 6 ¹( ( ƒ * º š ²r» «( 6Ž y ˆ* ^ º šr¼ ^ µ m 6ˆ} s½ ½½¾ ±( 6 6ˆ} s½à (º šuáâ ~  ~( Šr ³ 6 ( Ã( 6Ž ÄÄ š ¼ µ š r ²r» š Å} «( 6Ž y ˆŠr º š r ^ µ «( 6Ž y ˆŠr º š ²r» «6Ž( s ( Œ º šr¼ µ m 6 ˆ} sà À Ʊr 6 6ˆ} mà s½ º šá  ~  6Œ r6 Ã} 6Ž Ä Ä š ¼ ^ µ š } ²r»6 š ²r» «6Ž( y ŽŠr º šrç6²}¼ ^ µ š } ²r»6 š ( ^ µ š r ^ µ «( 6Ž y ˆŠr º š ²r» «6Ž( s ( Œ º šr¼ µ m 6 ˆ} sàà ½ Ʊr 6 6ˆ} s sè(º šuáâ ~  ~( Šr ³ 6 ( Ã( 6ŽÉŽ Ê ^ŒŒ }ƒ^ ÌË ¼ ^ŒÍÅ*ÄÄ š ¼ ^ µ6 š } ²r»6 š ²r» «6Ž( y ŽŠr º šr¼ µ m 6 ˆ} s ÀÈ ±( 6 6ˆ} s À À º šáâ ~(  ½ 0Î Ä Ä š ¼ ^ µ6 š } ²r»6 š ( ^ µ š ( Å} š ( µ6 š ( ^ µ «6Ž m~ 6 ¹( ( ƒ * º š ²r» «( 6Ž y ˆ* ^ º šr¼ ^ µ m 6ˆ} sè¾ Ï±( 6 ˆ} sðð º šáâ ~ Â Ñ rò ÄÄ š ¼ ^ µ6 š r ²r» š Å} «( 6Ž y ˆŠr º š r ^ µ «( 6Ž y ˆŠr º š ²r» «6Ž( s ( Œ º šr¼ µ m 6 ˆ} mî¾è ±( 6 6ˆ} sîà mº šáâ ~( Â Ó ŝ ² ± rò Ä Ä š ¼ ^ µ6 š } ²r»6 š ²r» «6Ž( y ŽŠr º šr¼ µ m 6 ˆ} mô¾ ±( 6 6ˆ} sô¾ È º šáâ ~(  s½ ÖÕ (ÄÄ š ¼ ^ µ š } ²r»6 š ( ^ µ š r ^ µ «( 6Ž y ˆŠr º š ²r» «6Ž( s ( Œ º šr¼ µ m 6 ˆ} OÕ¾¾ ±( 6 6ˆ} yõ½ ½ º šáâ ~(  ƒÿ }Žrƒ6ˆ}ÄÄ š ¼ ^ µ6 š } ²r»6 š ²r» «6Ž( y ŽŠr º šr¼ µ m 6 ˆ} mèð¾ ±( 6 6ˆ} sè¾ Î º šáâ ~(  s½ 0Ð (ÄÄ š ¼ ^ µ š } ²r»6 š ( ^ µ š ( Å} š ( µ6 š ²}³6ŕµ ~ Figura 2.4: Arquivo DTOR contendo instâncias de tipos de objetos complexos

29 2.3 Extração de Dados Extração de Dados Abordagem Baseada em Exemplos O ambiente DEByE propõe uma nova abordagem para o problema de extração de dados semiestruturados que envolve duas fases. A primeira fase consiste na especificação dos objetos relevantes para extração. A segunda fase consiste na extração propriamente dita dos objetos da fonte, com base nas diretivas fornecidas na primeira fase. A especificação dos objetos relevantes é feita através de exemplos fornecidos pelo usuário e envolve tanto a definição da estrutura dos objetos a serem extraídos quanto o contexto sintático em que esses objetos ocorrem na fonte. O resultado dessa especificação constitui a entrada para a fase de extração, o que torna a abordagem orientada a exemplos. A Seção descreve com mais detalhe esse processo de especificação de exemplos. Embora essa abordagem se aplique a diversos tipos de fontes de dados semi-estruturados, nesta dissertação a discussão será feita somente para o contexto de páginas HTML disponíveis em Web sites. Com base nessa abordagem, foi desenvolvida uma ferramenta chamada DEByE (Data Extraction by Example) [49]. Esta ferramenta é constituída de três módulos principais (Figura 1.1): um módulo de Interface Gráfica que é utilizado pelo usuário para especificação de exemplos dos objetos a serem extraídos, um módulo Extrator que, de posse das informações geradas pela interface gráfica, realizará a extração dos dados, e um módulo Visualizador que apresenta ao usuário os objetos extraídos e permite que o mesmo realimente o processo de especificação de exemplos, podendo assim melhorar o resultado da extração, caso seja necessário. De acordo com essa abordagem e usando a ferramenta em questão, a extração dos dados nas FDW (Fontes de Dados da Web) ocorre da seguinte forma. A partir de exemplos extraídos de uma página da Web, há a interação com a interface gráfica. Essa interação se dá através da especificação da estrutura que descreve os objetos que compõem essa fonte. Além dessa especificação, o usuário deverá delimitar trechos dessa página que representam exemplos típicos dos objetos a serem extraídos. Com base nessas diretivas, a interface gráfica fornece como saída estruturas de dados chamadas padrões para extração de objetos ou OE patterns (Object Extraction patterns). Os OE patterns constituem a entrada para o módulo que faz a extração de dados. Esse módulo usa os OE patterns para identificar em novos documentos das FDW objetos similares aos objetos de exemplo fornecidos pelo usuário. O resultado da extração feita por esse módulo é um conjunto de objetos complexos que podem ser vistos segundo o formato de tabelas aninhadas pelo modulo de vizualização. Através desse módulo, o usuário poderá fornecer novos exemplos ou mudar os exemplos especificados anteriormente, caso o resultado da extração não tenha sido satisfatório, ou seja, grande parte dos objetos não foram recuperados. Quando o usuário se der por satisfeito, o padrão de extração construído para essa determinada página poderá ser salvo.

30 16 Extração de Dados Semi-Estruturados Baseada em Exemplos Note que um OE pattern não precisa, necessariamente, estar associado a uma única página. A idéia é utilizar um mesmo padrão de extração em várias páginas dessa fonte de dados de estrutura semelhante (tais como as páginas retornadas como resultado de consultas a um mesmo site), de forma que o usuário tenha que especificar somente um padrão para extrair dados de todo um site, mesmo que ele seja constituído de muitas páginas de estruturas diferentes. No Capítulo 3, a ferramenta DEByE será discutida em detalhes Especificação dos Objetos de Exemplo A especificação da estrutura dos dados a serem extraídos de uma determinada FDW baseiase em uma tabela aninhada que descreve a hierarquia dos dados. Conforme já explicado na Seção 2.1, uma vez que os dados nessas fontes são em sua maioria semi-estruturados, a estrutura que os descreve nem sempre é regular. Desse modo, o modelo de dados adotado para representálos deve prover facilidades para a descrição de hierarquias heterogêneas. No modelo DEByE- OM, essa hierarquia é descrita através de objetos complexos. A Figura 2.5 mostra o arquivo DTOR gerado contendo objetos de exemplo que servirão como entrada para o módulo Extrator realizar a extração na fonte da Figura 2.1. š rœ} ŒŸžŽ( ˆ^ * r + 0 š rœ} Œhªjˆ* «6Œ(Ž6ŝ 6ŽŽr «6Ž O Ž œ 6 œ ˆ(Œ ^ Ž(± O6Žˆ* Ž ƒ[ œ ˆ(Œ š²}³ }µ ~ шr } ^ ŠrŽr Ž ±É Ø * } Ž^ rù^ ( m6ž r Ž6ˆ*Ž^ rƒ^ž}ò«ž Ū NÒ ^± ±^Ž} 6¹rÙ^ º š ( ^ µ «6Ž m~ 6 ¹( ( ƒ * º š ²r» «( 6Ž y ˆ* ^ rƒ^ ( ^ ( «^ O 6Ž º šr¼ ^ µ m 6ˆ} mô ¾Ô ϱ( 6 ˆ} sô ½¾ ÚŠr r ^ sð º šáâ ~(  ~^ Ž( } ¼ Ž^Œ 6ˆ} ÄÄ š ¼ ^ µ6 š r ²r» š Å} «( 6Ž y ˆŠr º š r ^ µ «( 6Ž y ˆŠr º š ²r» «6Ž( s ( Œ rƒ ( ( «y Ž º šr¼ µ m 6 ˆ} sô sàð ±( 6 6ˆ} sôî mà ÛŠr } ^ ^ mð º šáâ ~(  6ŒrÜ 6Ž ~ r^ r^ƒ^ ~^ Žr r6 Ä Ä š ¼ ^ µ^ š } ²r»6 š ²r» «6Ž( y ŽŠr rƒ^ ( ^ ( «^ O 6Žrº šr¼ µ m 6 ˆ} sô ÎÀ½ ±( 6 6ˆ} sôô Ô ÛŠr } ^ ^ mð º šáâ ~(  sð O s (Ä Ä š ¼ µ6 š } ²r»6 š ( ^ µ š ( Å} š ( µ6 š ²}³6ŕµ ~ Figura 2.5: Arquivo DTOR contendo instâncias de tipos de objetos complexos Analisando o arquivo da Figura 2.5, pode-se perceber dois atributos adicionais, count e mandatory, que não estavam presentes no arquivo mostrado na Figura 2.4. Isso se deve ao fato desses atributos serem relevantes apenas para o processo de geração dos padrões para extração e para o processo de extração propriamente dito. Esses atributos correspondem às propriedades Count e Mandatory que representam, respectivamente, a cardinalidade ou o número aproximado de instâncias correspondente a cada objeto do tipo atômico fornecido como exemplo e a

31 T T 2.3 Extração de Dados 17 obrigatoriedade da presença de um determinado objeto no resultado da extração. O arquivo da Figura 2.4 representa o resultado da extração, ou seja, representa um estado no qual essas propriedades já foram utilizadas e não são mais necessários. Os valores dessas duas propriedades podem ser fornecidas pelo usuário no momento da especificação dos exemplos, utilizando a Interface Gráfica da ferramenta de forma bastante simples, como se pode ver na Seção Padrão para Extração de Objetos Os padrões para extração de objetos, ou OE Patterns como serão mencionados a partir de então, nada mais são do que padrões genéricos construídos com base nos objetos de exemplo fornecidos durante a primeira fase do processo de extração dessa abordagem, a de Especificação de Exemplos. Ao final dessa fase, os valores dos objetos componentes do exemplo são substituídos por padrões de texto (expressões regulares) que serão utilizados posteriormente pelo extrator, para identificar valores de novos objetos atômicos componentes de outros objetos complexos presentes na fonte de dados onde está ocorrendo o processo de extração. Os OE Patterns contêm informação sobre: a estrutura dos objetos a serem extraídos; o contexto associado a cada objeto do tipo atômico componente dos objetos comlexos a serem extraídos Esse contexto é derivado das posições na página de amostra que circundam os valores dos objetos fornecidos como exemplo. Esses valores estão presentes no arquivo que contém os objetos de exemplo (Figura 2.5), sendo eles ipos e fpos, posição inicial e final, repectivamente. A informação sobre o contexto é utilizada para gerar padrões para extração de valores de objetos atômicos. Esses valores são chamados padrões de pares atributo-valor ou AVP patterns e são discutidos a seguir. AVP Patterns Quando o usuário especifica um exemplo, cada valor é associado a um atributo (objeto atômico). Por esse motivo, utiliza-se o termo par atributo-valor (AVP) para referenciar um atributo (objeto atômico) e um de seus valores. Como exemplo, tem-se na Figura 2.5 o valor Caetano Veloso X ZY X6 Y ^ J U_J para o atributo V+W constituindo o par R<VJW, Caetano VelosoS, bem como R?], \ Alguem Cantando CaetanoS, 16.10S. e R?` W a Para que se possa reconhecer automaticamente novos objetos em novas páginas, é preciso que os AVPs correspondentes a esses novos objetos sejam encontrados. Assim, introduziuse a noção de contexto local para cada par atributo-valor. Os contextos locais são derivados

32 ` ` V a a a ` a W ` ` Y a V a a a 18 Extração de Dados Semi-Estruturados Baseada em Exemplos do texto onde o AVP ocorre da seguinte maneira. Considere a posição no texto (ou em uma página HTML) de um valor fornecido como exemplo pelo usuário. As palavras ou tokens que cercam esse valor constituem uma passagem (ou janela) [9, 14, 31] que pode ser usada com um \ contexto local para esse valor. Por exemplo, a Figura 2.7 ilustra o valor do tipo `+Wa (que ocorre na página do site CD Studio como ilustrado na Figura 2.6) e uma passagem que pode ser usada com o seu contexto local. Usando essa informação de contexto, é construído um padrão para extração de atributos (AVP pattern) que pode ser posteriormente utilizado para \ identificar outros valores do tipo `+W a. A Figura 2.8a ilustra uma possível representação para esse AVP pattern. Neste padrão, o * casa (match) com qualquer sequência de caracteres de qualquer comprimento. +Y Y ÝU _J+X Þ _ ß +Y a Ý+ ZY Ý Z +Y Y ÝU a6à á_jâ J_ ãj Z +Y Y ÝUë +Y Ý+ Y J_ Wåä+äJäJäJäJä+äJäJäJäJä+äJäJäJäJä+äJäJäJä4 hæèçéfä}çê á_jâ J_ ãj Z äì +Y Ý+ Y Ý í[ \Jïî JÝ+ h+x Wåä+äJäJäJäJä+äJäJäJäJä+äJäJäJäJä+äJäJäJä4 hæèçêfäìjê ^ðu J_ ã+ß àñäjä+äjäjäjäjä+äjäjäjäjä+äjäjäjäjä+äjäjäjäjä+äjäjäò hæèç^ó7äôjê Figura 2.6: Extrato de uma página do site CD Studio J_ ãj Z Wåä+äJäJäJäJä+äJäJäJäJä+äJäJäJäJä+äJäJäJä hæ çéfä}çê +Y Y ÝUë +Y Ý+ Y J_ äoì á_+âu Figura 2.7: Exemplo de um contexto AVP J_ ã+ Z WõäJäJä+äJäJäJäJä+äJäJäJäJä+äJäJäJäJä+äJä Uæ ö +Y Y ÝUë +Y Ý+ Y +_ äì á_jâ (a) äjäjäjäjä+äjäjäjäjä+äjäjäjäjä+äjäjäjäjä hæ ö Y Y Ý Y Ý+ Y J_ äì (b) Figura 2.8: Exemplos de padrões AVP Note que o padrão gerado na Figura 2.8a é possivelmente muito restrito para identificar outros preços de discos em novos objetos. Para torná-lo um pouco mais flexível, é utilizado um procedimento iterativo que reduz a largura do padrão inicialmente gerado até que ele se torne genérico o suficiente para identificar preços de livro em geral. Isto é feito testando-se padrões cada vez menores nos objetos existentes (implicitamente) em uma página de amostra. A Figura 2.8b mostra uma variação do AVP pattern gerado para o valor após ter reduzido o tamanho do prefixo e sufixo do contexto que o envolve. Em geral, um AVP pattern é gerado da seguinte forma. Dado um par atributo-valor informado pelo usuário, determina-se uma passagem em torno desse valor no texto (página da Web).

33 2.3 Extração de Dados 19 Neste trabalho, as passagens são simétricas, compostas de W tokens textuais para a esquerda e W tokens textuais para a direita do valor AVP. A largura W de um padrão AVP é determinado empiricamente para cada tipo de AVP. Começa-se com um pequeno padrão composto somente do símbolo ö, de um token à direita e um à esquerda. Esses tokens podem ser uma cadeia de caracteres ou símbolos especiais (como *, $, -, etc.). Por exemplo, na Figura 2.8b, o padrão \ AVP inicial para o tipo ` W a poderia ser composto pelo símbolo ö circundado pelo prefixo... R$ e pelo sufixo Caetano Canta Vol.2. Em seguida, faz-se um parsing na página em questão utilizando esse AVP pattern criado inicialmente e conta-se o número de casamentos (matches) encontrados. Depois, esse número é comparado com o valor da propriedade Count fornecida pelo usuário (seção anterior) para esse tipo de objeto. Se o número de casamentos ultrapassar o valor fornecido pelo usuário, então novos termos são adicionados ao padrão, aumentando assim a largura W e a quantidade de informação contextual em torno dele. Esse processo continua, mantendo-se o máximo possível a simetria, até que um padrão gerado é tal que com ele é possível identificar a maior parte dos objetos disponíveis nas páginas. O processo acaba quando o número de casamentos dos padrões for menor ou igual ao valor fornecido pelo usuário em relação à propriedade Count. Através deste processo, é possível gerar padrões que são flexíveis o suficiente para identificar novos valores (que apareçam em novas páginas) ao mesmo tempo em que o contexto local original é mantido tanto quanto possível. Vale comentar que, para cada objeto atômico de exemplo, é possível gerar um AVP pattern de tamanho distinto. Por exemplo, o AVP pattern para título do disco pode ser menor que o AVP pattern para o seu preço. Caso o usuário não forneça valores para a propriedade Count para os objetos de exemplo, é assumido uma largura W igual a 1. De acordo com o processo de geração dos AVPs, percebe-se que com uma passagem deste tamanho o número de objetos recuperados pode não atender aos interesses do usuário, pois o resultado da extração, seguindo essa especificação, provavelmente conterá muitos dados inválidos. Os AVP patterns são usados para compor os Object Extraction (OE) patterns, que serão discutidos a seguir. OE Patterns Os padrões para extração de objetos ou OE (Object Extraction) patterns são gerados a partir dos objetos de exemplo fornecidos pelo usuário (Figura 2.5). Conforme mostrado na Figura 1.1, os OE patterns servem para alimentar o módulo Extrator que realiza a extração de novos objetos em outras páginas da Web. Esses padrões para extração de objetos trazem informação sobre a estrutura dos objetos e sobre os AVP patterns associados aos atributos desses objetos. Esses padrões são descritos usando uma notação baseada em XML similar à usada para descrever os objetos de exemplos. A diferença é que os AVPs presentes no arquivo que contém os objetos de exemplo são substituídos pelos AVP patterns correspondentes. A Figura 2.9 mostra um exemplo

34 20 Extração de Dados Semi-Estruturados Baseada em Exemplos de um arquivo contendo os AVP patterns correspondentes aos objetos de exemplo da Figura 2.5. š rœ} ŒÉžŽ( ˆ^ } r Ø + 0 øš }œ} ŒUªjŝ «6Œ Ž6ˆm 6ŽŽ( Û «Ž y Ž œ 6 œ ˆrŒ 3 Ž ± 6Ž6ˆ* Ž(ƒ[ œ ˆ(Œ6 š²*³ ŕµ ~ ˆr r ^ ŠrŽr ^ Ž(±ø s } 6 Ž rù ( y6ž^ r Ž^ˆrŽ^ }ƒ^ž}ò^«^žū tò ^±±Žr 6¹*Ù º š ( ^ µ «Ž m~ ¹ ( ^ƒ } º š ²}» «6Ž y (ˆ* rƒ ( ( «y Ž º š µùç6 šáâ ~ Âúš Ž ḧâ ^ˆ*Ä û š ˆ* rü Ü ŝä û ü6â œ Î ^Ë œ Ô ³ œ Ôr œ Ô( ^Ë œ ¾ µ œ Ë œ ^Äý 6þJü{  ˆ}Ä û š ˆm ^ }Ü Â ˆ*Ä6û ª þ ÄÄ š } µ(ùç š r ²r»6 š Å} «6Ž y ˆŠ} º š ( µ «6Ž y ˆŠ} º š ²r» «( 6Ž s Œ }ƒ^ ( r «^ y 6Ž º š µ ùç6 šá  ~ Âúš Ž  ˆ}Äû š ¾ µ œ Ë œ Äý 6þJüj  ˆ}Ä6û š  ^ˆ}Ä6û (š (Ž þ Ä(Ä š r µù(ç6 š r ²}»6 š r µùç6 š r ²}»6 š ( ^ µ6 š ( Å* š r ^ µ6 š ²}³ ŕµ ~ Â{ÿ*š Äý  ˆ}Ä û ü  œ Î ^Ë œ Ô ³ œ Ôr œ Ô( ^Ë œ š ²r» «( 6Ž y Ž6Šr r^ƒ^ ( ( «^ y ( 6Ž º š µ ùç6 šá  ~   ˆ}Ä û ü  ^Ë À(Äý U Â Ë ÀrÄý þ üj  ˆ}Ä6û š ˆm ^ }^Ü 6þ ÄÄ Figura 2.9: Padrões para extração gerados para os objetos de exemplo da Figura 2.5 Para páginas contendo objetos não homogêneos (páginas onde existe mais de uma estrutura para os objetos que a compõem), o usuário pode ter que especificar mais de um objeto de exemplo, de forma a fazer com que uma fração maior dos objetos implicitamente presentes em novas páginas seja extraída. Desta forma, é gerado um padrão para extração para cada novo objeto fornecido como exemplo. A Figura 2.11 ilustra os OE patterns gerados para dois exemplos distintos especificados (Figura 2.10) para a página de amostra do site CD Studio da Figura 2.1. Analisando esses padrões de extração, pode-se perceber que a presença do atributo mandatory. Isso acontece porque, como já mencionado, esses padrões irão alimentar o Extrator e este utiliza os valores dos esta informação para montar de forma adequada os objetos complexos extraídos de acordo com a especificação do usuário Estratégia de Extração Adotada pela DEByE Conforme já mencionado, o módulo Extrator (Figura 1.1) recebe um conjunto de OE patterns do módulo de Interface Gráfica e utiliza-os para identificar novos objetos em novas páginas fornecidas como entrada. Existem basicamente duas estratégias para realizar a extração de objetos propriamente dita: uma top-down [45] e outra bottom-up [44]. Em [44], as duas estratégias são comparadas e são apresentados resultados experimentais que demonstram que a estratégia bottom-up é bastante superior à estratégia top-down. Devido a isto, adotou-se para

35 2.3 Extração de Dados 21 š rœ} ŒŸž^Ž( ˆ^ } } J 0 š rœ} ŒUª ˆ* «6Œ Žŝ 6ŽŽ( Û «( 6Ž y ^Ž œ 6 œ ˆ(Œ ^ Ž ± O6Ž6ŝ Ž ƒ[ œ ˆ(Œ š ²}³ ŕµ ~ ˆr r ŠrŽr ^ ^Ž ±É * } 6 Ž^ rù ( m6ž^ r Ž6ˆrŽ (ƒžrò «Ž^ Z NÒ ± ±Ž( ^¹rÙ^ º š ( ^ µ «( 6Ž m~(6 ¹ ( ( ƒ * (º š ²r» «6Ž( y ˆ* }ƒ^ ( r «^ y 6Ž º šr¼ µ m 6 ˆ} sô ¾Ô ±( 6 6ˆ} sô ½ ¾ ÚŠ} r ^ ^ sð º šáâ ~  ~ Ž( r ¼ Ž^Œ 6ˆr (ÄÄ š ¼ ^ µ^ š } ²r»6 š Å} «6Ž( y ˆ Šr º š ( ^ µ «Ž y (ˆŠr º š ²}» «6Ž s 6Œ rƒ^ r ( «^ y 6Ž(º šr¼ ^ µ m 6 6ˆ} sô sà Ð ±r 6 6ˆ} sôî sà ÛŠr r ^ ^ sð º šáâ ~  ŒrÜ 6Ž ~^ }^ rƒ ~^ Ž( }6 ÄÄ š ¼ ^ µ š r ²r»6 š ²}» «6Ž y Ž6Š} }ƒ^ ( r «^ y 6Ž º šr¼ ^ µ m 6 6ˆ} sôîà ½ ±r 6 6ˆ} sôô Ô ÛŠr r ^ ^ sð º šáâ ~  mð O s Ä Ä š ¼ µ6 š r ²r»6 š r ^ µ6 š r Å} š ( ^ µ6 š ( ^ µ «( 6Ž m~(6 ¹ ( ( ƒ * º š ²r» «6Ž( y ˆ* }ƒ^ ( r «^ y 6Ž º šr¼ µ m 6 ˆ} yõ¾ ¾ Ʊr 6 6ˆ} OÕ¾ÎÈ ÚŠr r ^ sð º šáâ ~ ÂN¼ m (Š^ y ˆ Ž» ( ^ Ž6ˆ}ÄÄ š ¼ µ š } ²r»6 š Å} «6Ž( y ˆ Šr º š ( ^ µ «Ž y (ˆŠr º š ²}» «6Ž s 6Œ rƒ^ r ( «^ y 6Ž(º šr¼ ^ µ m 6 6ˆ} yõ½ô(õ Ʊ( 6 ˆ} yõ½rõ¾ ÛŠ} r ^ ^ sð º šáâ ~ Â É Šr øž Ç Ž ÄÄ š ¼ ^ µ6 š r ²r»6 š ²}» «6Ž y Ž6Š} }ƒ^ ( r «^ y 6Ž º šr¼ ^ µ m 6 6ˆ} yõààè Ʊ( 6 ˆ} yõà ÀÀ ÛŠ} r ^ ^ sð º šáâ ~  ½ 0Ð (ÄÄ š ¼ µ š r ²r»6 š r ^ µ6 š r Å} š ( ^ µ6 š ²}³ ŕµ ~ Figura 2.10: Arquivo DTOR contendo dois objetos complexos CD Studio como exemplo a DEByE a estratégia de extração bottom-up. A seguir, encontra-se uma breve descrição da implementacação dessa estratégia. A Figura 2.13 apresenta o algoritmo bottom-up descrito em [44]. Esse algoritmo recebe como entrada um OE pattern O e (como ilustrado na Figura 2.9) e um conjunto G de novas páginas. Ao invés de usar um OE pattern para reconhecer os objetos nessas páginas, o algoritmo usa diretamente os padrões AVP (Attribute-Value Pair). Para cada padrão AVP do OE pattern de entrada, são extraídos todas as strings que casam com ele. Cada string encontrada é então inserida na variável AVP BAG como triplas no formato R A, s, l S, onde A é o tipo do objeto e l é a posição da ocorrência da string s na página G. Essa é a chamada Fase de Extração do algoritmo. Seguindo o exemplo de extração que está sendo usado no site CD Studio, uma dessas triplas poderia ser R V+W, Caetano Veloso, 13073S. Essas triplas são X ZY usadas posteriormente para montar os novos objetos que farão parte do resultado da extração,

36 22 Extração de Dados Semi-Estruturados Baseada em Exemplos š rœ} ŒÉžŽ( ˆ^ } r Ø + 0 øš }œ} ŒUªjŝ «6Œ Ž6ˆm 6ŽŽ( Û «Ž y Ž œ 6 œ ˆrŒ 3 Ž ± 6Ž6ˆ* Ž(ƒ[ œ ˆ(Œ6 š²*³ ŕµ ~ ˆr r ^ ŠrŽr ^ Ž(±ø s } 6 Ž rù ( y6ž^ r Ž^ˆrŽ^ }ƒ^ž}ò^«^žū tò ^±±Žr 6¹*Ù º š ( ^ µ «Ž m~ ¹ ( ^ƒ } (º š ²}» «6Ž y (ˆ* rƒ ( ( «y Ž º š µùç6 šáâ ~ Âúš Ž ḧâ ^ˆ*Ä û š ˆ* rü Ü ŝä û ü6â œ Î ^Ë œ Ô ³ œ Ôr œ Ô( ^Ë œ ¾ µ œ Ë œ ^Äý 6þJü{  ˆ}Ä û š ˆm ^ }Ü Â ˆ*Ä6û ª þ ÄÄ š } µ(ùç š µùç6 šáâ ~ Âúš Ž ḧâ ^ˆ*Ä û š ˆ* rü Ü ŝä û ü6â œ Î ^Ë œ Ô ³ œ Ôr œ Ô( ^Ë œ ¾ µ œ Ë œ ^Äý 6þJü{  ˆ}Ä û š ˆm ^ }Ü Â ˆ*Ä6û ª þ ÄÄ š } µ(ùç š r ²r»6 š Å} «6Ž y ˆŠ} º š ( µ «6Ž y ˆŠ} º š ²r» «( 6Ž s Œ }ƒ^ ( r «^ y 6Ž º š µ ùç6 šá  ~ Âúš Ž  ˆ}Äû š Â{ÿ*š Äý  ˆ}Ä û ü  œ Î ^Ë œ Ô ³ œ Ôr œ Ô( ^Ë œ ¾ µ œ Ë œ Äý 6þJüj  ˆ}Ä6û š  ^ˆ}Ä6û (š (Ž þ Ä(Ä š r µù(ç6 š µ ùç6 šá  ~ Âúš Ž  ˆ}Äû š ¾ µ œ Ë œ Äý 6þJüj  ˆ}Ä6û š  ^ˆ}Ä6û (š (Ž þ Ä(Ä š r µù(ç6 š r ²}»6 Â{ÿ*š Äý  ˆ}Ä û ü  œ Î ^Ë œ Ô ³ œ Ôr œ Ô( ^Ë œ š ²r» «( 6Ž y Ž6Šr r^ƒ^ ( ( «^ y ( 6Ž º š µ ùç6 šá  ~   ˆ}Ä û ü  ^Ë À(Äý U Â Ë ÀrÄý þ üj  ˆ}Ä6û š ˆm ^ }^Ü 6þ ÄÄ š r µùç6 š µ ùç6 šá  ~  š r µùç6 š r ²}»6 š ( ^ µ6 š ( Å* š r ^ µ6 š ²}³ ŕµ ~  ˆ}Ä û ü  ^Ë À(Äý U Â Ë ÀrÄý þ üj  ˆ}Ä6û š 6þ Ä Ä Figura 2.11: Padrões de extração gerados para os objetos de exemplo da Figura 2.10 consituindo então a segunda fase do algoritmo que é a Fase de Montagem. A posição l é usada para distinguir quais triplas R A, s, l S compõem o mesmo objeto complexo. Na sequência, é definido que o atributo mais à esquerda do OE pattern de entrada será tratado com uma marca especial. A leitura de um elemento deste tipo marcará o fim do objeto corrente e o início de outro objeto. Para ilustrar, considere o objeto da Figura 2.2. Esse objeto [ X Y inclui 3 AVPs e o AVP R VJW, Caetano VelosoS é o mais a esquerda. A segunda fase do algoritmo utiliza a lista AVP BAG. Enquanto houver triplas na lista AVP BAG, é feito o seguinte: seleciona-se uma tripla R A, s, l S da lista de triplas em AVP BAG com a menor posição l. Se o tipo do objeto escolhido for o tipo do objeto mais à esquerda da estrutura OE pattern, então o objeto complexo atual é incluído no arquivo DTOR de saída. Deve-se notar, porém, que esse objeto só é incluído nesse arquivo depois de verificar as restrições de obrigatoriedade (atributo mandatory = true) de todos os seus componentes. Em geral, para objetos com estruturas hierárquicas de muitos níveis, o OE pattern O e é uma sub-hierarquia de um OE pattern, digamos O f, correspondente a objetos mais complexos. Assim, após serem identificados e extraídos todos os objetos correspondentes a O e, eles serão usados para compor os objetos mais complexos correspondentes a O f. Este procedimento é executado a partir dos níveis inferiores da hierarquia do OE pattern até os níveis superiores.

37 2.3 Extração de Dados 23 Devido a isso, essa estratégia de extração recebe o nome de Bottom-up. A Figura 2.12 pode ilustrar melhor isso. Nessa figura, os círculos representam os AVPs que foram extraídos durante a Fase de Extração do algoritmo. Para cada um desses objetos, existe um rótulo li associado. Esse rótulo se refere à posição da string correspondente ao AVP na página onde foi realizada a extração. ^ J U_J \ No passo 1, pares de objetos ] e `+W a são combinados para montar o objeto complexo X+\ e, no passo 2, um conjunto de instâncias de XJ\J são agrupadas em uma lista de instâncias de XJ\, indicada como b JXJ\ d. No passo 3, o que seria feito é simplesmente X ZY combinar os pares de objetos V+W e JXJ\ para montar o objeto complexo CD Studio. Esses três passos correspondem à Fase de Montagem do algoritmo. Essa fase de montagem pode ser executada inúmeras vezes, variando de acordo com os níveis de hierarquia do OE pattern. Passo Passo Titulo Preco Disco {Disco} Artista 12 Figura 2.12: Execução do algoritmo bottom-up A principal característica desta estratégia é que a composição de um novo objeto só é feita depois que os valores individuais dos seus atributos são identificados através dos AVP patterns. Isto significa que um novo objeto será montado mesmo se houver atributos faltando e isso não interferir na restrição de obrigatoriedade desse objeto, ou mesmo que a ordem em que os atributos ocorrem na página mude de objeto para objeto. Esta característica confere grande flexibilidade à extração que assim apresenta resultados muito bons. Os objetos após serem extraídos e montados são armazenados em arquivos DTOR. A Figura 2.4 mostra um exemplo do resultado da extração que foi realizada na fonte de dados do site CD Studio (Figura 2.1) utilizando os objetos de exemplo presente em (Figura 2.5) e o seu respectivo OE pattern (Figura 2.9). Utilizando a estratégia de extração bottom-up é possível demonstrar que a DEByE pode ser efetivamente utilizada para extrair novos objetos de novas páginas. Isto será demonstrado experimentalmente no Capítulo 4.

38 24 Extração de Dados Semi-Estruturados Baseada em Exemplos Algoritmo Bottom-up de Extração inicio Ler um conjunto G de paginas da Web; Ler o OE pattern correspondente aos objetos de exemplo especificado pelo usuario; Fase de Extração para cada pagina g do conjunto de paginas G faça /* Extrai todos os AVPs das paginas e armazena-os em uma lista AVP BAG */ AVP BAG /0; para cada AVP do atributo A do OE pattern O e faça Identifica o padrão p correspondente ao AVP pattern de A; para cada string s que casa com p em g faça Obtem a posição l de s em g; /* Armazena a tripla A s l na lista de triplas AVP BAG */ AVP BAG AVP BAG A s l ; fim fim fim /* Monta os objetos extraidos usando as triplas de AVP BAG */ /* Os objetos extraidos possuem uma estrutura similar aos O e.*/ /* Cria uma marca que identifica o comeco da montagem de um novo objeto*/ MARK A; Cria um novo objeto O com a estrutura de O e ; Fase de Montagem enquanto AVP BAG /0 faça inicio Obtem a tripla de menor posicao l da lista AVP BAG; se A = MARK then inicio Verifica as restricoes de mandatoriedade dos atributos do objeto corrente; Inclui o objeto corrente no arquivo de saida de acordo com as restricoes de mandatoriedade; fim Atribui s como valor do atributo A em O; Remove a tripla A s l da lista AVP BAG; fim fim Figura 2.13: Visão geral do algoritmo bottom-up

39 T Capítulo 3 Realimentação de Exemplos na DEByE 3.1 Visão Geral da DEByE Como já descrito no Capítulo 2, a ferramenta DEByE (Data Extraction By Example) [34] é composta atualmente de três módulos principais: uma Interface Gráfica, também conhecida por DEByE GUI (Graphical User Interface), um módulo Extrator e um módulo Visualizador. Neste capítulo serão apresentados detalhes de como se dá a interação entre esses três módulos, enfocando principalmente o módulo Visualizador, que é responsável pelo processo de realimentação de exemplos. Esse processo consitui uma extensão importante em relação à versão anterior da ferramenta [49], sendo um recurso extremamente poderoso pois permite que o usuário, através dele, consiga melhorar a precisão da extração de dados das FDW (Fontes de Dados da Web). A Figura 3.1 apresenta a tela mostrada durante uma sessão típica de extração de dados através da DEByE. Essa tela ilustra vários dos recursos disponíves, os quais serão descritos a seguir considerando cada um dos módulos da ferramenta: Interface Gráfica A Interface Gráfica é o módulo que permite ao usuário especificar os objetos de exemplo. Esse módulo inclui três janelas distintas: a Source Window, a Example Window e a Extraction Pattern Window. Ao começar uma sessão típica de extração de dados, apenas essas três janelas são mostradas incialmente ao usuário. A janela Source Window mostra a página de um site da Web escolhido pelo usuário. Na Figura 3.1, a página mostrada é da loja virtual de venda de discos CD Studio [16] que está sendo usada ao longo da discussão desta dissertação. A janela Example Window é usada para a montagem do objeto de e- xemplo. Essa janela é apresentada ao usuário no início da sessão completamente vazia e o seu formato busca sugerir que (a) um objeto de exemplo pode ser composto de vários atributos (ou colunas) e (b) diversos objetos de exemplo podem ser fornecidos, o que se torna necessário quando a estrutura dos objetos a serem extraídos apresenta variações. A janela Extraction Pattern Window é utilizada somente ao final da sessão para gerar os OE 25

40 T T 26 Realimentação de Exemplos na DEByE Figura 3.1: Tela de uma sessão típica de extração através da ferramenta DEByE patterns e invocar o módulo Extrator que realiza a extração dos objetos das páginas da Web. Extrator Esse módulo pode ser considerado um mediador entre a Interface Gráfica e o módulo Visualizador. Conforme ilustrado no ambiente DEByE (Figura 1.1), esse módulo recebe como entrada, do módulo de Interface Gráfica, um OE Pattern recém gerado e utiliza-os para identificar novos objetos na página de amostra ou em outras páginas da mesma fonte de dados. Para tanto, o extrator utiliza a estratégia de extração Bottom-up como explicado na Seção Após realizar a extração dos objetos da FDW escolhida pelo usuário, o Extrator armazena os objetos extraídos em um arquivo DTOR (DEByE Textual Object Repository) (Seção 2.2.1), que é então enviado ao módulo Visualizador para visualização do resultado da extração. Visualizador O Visualizador é o módulo responsável por apresentar ao usuário os objetos que foram extraídos da fonte de dados de interesse. Esse módulo recebe do Extrator um arquivo DTOR e o visualiza na forma de tabelas aninhadas. O resultado da visualização é apresentado ao usuário através da janela Extraction Result Window que não está disponível no início da sessão de extração. O usuário só tem acesso a esse recurso quando o resultado da extração está para ser mostrado. Essa janela permite ao usuário examinar os objetos extraídos e verificar se algum objeto deixou de ser extraído ou foi extraído parcialmente. Nesse caso, o usuário pode realimentar o processo de extração selecionando da Extraction Result Window, um objeto parcialmente extraído, para ser usado como um novo exemplo.

41 3.2 Especificação de Exemplos 27 A seguir, poderá criar um novo OE Pattern e reninicar o processo de extração novamente. Esse ciclo pode perdurar até que o usuário se satisfaça com o resultado da extração obtido. É importante observar que um mesmo padrão de extração (OE pattern) poderá ser usado na extração de objetos de qualquer página da mesma fonte de dados, que for similar, em contexto e estrutura, à página para a qual o padrão foi gerado. 3.2 Especificação de Exemplos Para assistir o usuário na tarefa de especificar os objetos de exemplo, a Interface Gráfica adota a metáfora de tabelas aninhadas conforme apresentado na Seção 2.2. Como já dito, tabelas aninhadas constituem uma forma simples e intuitiva para representar objetos complexos com estrutura hierárquica, usualmente encontrados em páginas da Web. A Figura 3.2 apresenta parte da tela da ferramenta DEByE capturada durante o processo de especificação de exemplos. Figura 3.2: Tela capturada durante a especificação de exemplos através da ferramenta DEByE Para montar um objeto de exemplo, o usuário deve marcar porções de texto da página de amostra na Source Window e copiá-las para as colunas da Example Window. Para que esta operação seja realizada com facilidade, a Interface Gráfica dispõe de recursos de edição e copy-and-paste (copiar-e-colar). Além disso, a ferramenta dispõe de diversas operações de estruturação de tabelas. Entre elas, estão as operações insert, remove, rename, group, e split. Todas essas operações estão disponíveis através da janela Operations on Columns (Figura 3.3). Essa janela possibilita ainda que o usuário especifique as propriedades de cada coluna. Para ativar essa janela, basta que o usuário dê um clique em qualquer uma das colunas da janela

42 28 Realimentação de Exemplos na DEByE Example Window. Figura 3.3: Operações para estruturação de tabelas As três primeiras operações permitem, respectivamente, inserir, remover e alterar o nome das colunas. Na Figura 3.2, por exemplo, o usuário executou uma operação de inserção de coluna (note que agora existem três colunas quando incialmente a interface é apresentada com X6 Y ^ J U_J \ duas) e alterou seus nomes para VJW, ], e ` W a. Note que existe também uma operação para alterar o nome da tabela, que neste caso recebeu o nome CD Studio. A Figura 3.4 mostra a mesma janela Example Window da Figura 3.2 após o resultado de U_J \ uma operação do tipo group realizada sobre as colunas ] e `+W a para construção de uma tabela aninhada chamada XJ\J. Isto foi feito para representar o fato de que na página de amostra, a cada artista (neste caso, Caetano Veloso ) está associado a um conjunto de discos dos quais se tem o título e o preço. Isto significa que o exemplo especificado descreve objetos complexos cuja estrutura é uma hierarquia de dois níveis (ver Figure 2.2). Implicitamente, cada linha de uma tabela aninhada corresponde a um exemplo de um objeto complexo presente na página de amostra. A operação split permite que o usuário reverta a operação group realizada. As propriedades de cada coluna (Figura 3.3) simbolizam, respectivamente, o número aproximado de vezes que cada atributo da tabela (representado pelas colunas) ocorre na página da Web em questão e se esse atributo deve aparecer, ou não, obrigatoriamente no resultado da extração. Para que o usuário estime as ocorrências de cada coluna, basta que o mesmo navegue rapidamente pela página de onde se está fornecendo os objetos de exemplo e verifique quantas vezes aproximadamente cada coluna comparece. Em seguida, basta inserir este valor na caixa de texto ao lado do rótulo Estimated Number of Occurrences. Para dizer se uma coluna será obrigatória ou não, o usuário deverá analisar mediante o contexto da página de amostra, o que realmente é importante que seja extraído e então clicar o botão Yes ou No que está ao lado do rótulo Is a Mandatory Column?. É importante observar que essas propriedades correspondem aos atributos count e mandatory do arquivo DTOR correspondente. Após a especificação os objetos de exemplo, o usuário poderá prosseguir com o processo de extração passando ao próximo passo, a geração dos padrões (OE patterns) correspondentes

43 3.3 Geração dos Padrões para Extração 29 a esses objetos, que serão então posteriormente usados pelo módulo Extrator para realizar a extração na página de amostra apresentada. 3.3 Geração dos Padrões para Extração Uma vez especificados os objetos de exemplo, o usuário utiliza o botão Build na janela Extraction Pattern Window para construir um Object Extraction (OE) pattern, que consiste de uma descrição de como os dados existentes na página de amostra devem ser dela extraídos e combinados para formar objetos complexos de estrutura similar aos exemplos fornecidos na Example Window. O botão Build possui duas funções ímplicitas: primeiramente, gera o arquivo DTOR contendo os objetos de exemplo que foram especificados na Example Window e, em seguida, analisa e generaliza os contextos textuais dos dados selecionados pelo usuário para montagem dos objetos de exemplo (Seção 2.3.3), gerando assim os OE patterns correspondentes. A janela Example Window da Figura 3.4 inclui o objeto de exemplo mostrado na Figura 2.5. Os seus respectivos OE patterns foram mostrados na Figura 2.9. É importante relembrae que, os OE patterns contêm informação sobre a estrutura dos objetos a serem extraídos e o contexto associado a cada atributo componente desses objetos, e que, é através desses padrões que o módulo Extrator consegue realizar a extração em outras páginas da mesma fonte de dados da página de amostra. Figura 3.4: Exemplo de criação de uma tabela aninhada através da operação group 3.4 Extração de Dados da Página de Amostra Continuando com processo de extração na página de amostra fornecida pelo usuário, o passo a seguir é a extração propriamente dita. Para tanto, o usuário deverá acionar o botão Extract da Extraction Pattern Window que já estará habilitado para tal ação. Esse botão só é habilitado depois que o OE pattern correspondente aos objetos de exemplo especificados foi gerado.

44 30 Realimentação de Exemplos na DEByE A função do botão Extract é invocar o módulo Extrator, fornecendo como entrada o OE pattern corrente e a página de amostra apresentada na Source Window, para que ele realize a extração dos dados da mesma. Ao finalizar a extração, os objetos extraídos são armazenados em um arquvio DTOR e, automaticamente, o módulo Visualizador é chamado para apresentá-los ao usuário. Uma parte do arquivo DTOR, contendo o resultado da extração efetuada na página de amostra do site CD Studio, utilizando o objeto de exemplo da Figura 3.4 e seu respectivo OE patterns, foi mostrado na Figura Visualização do Resultado da Extração O módulo Visualizador recebe do Extrator o arquivo DTOR contendo os objetos que foram extraídos da página de amostra. Em seguida, esse arquivo é analisado e manipulado por métodos disponíveis nas bibliotecas DOM (Document Object Model) [60], que é uma biblioteca para manipulação de arquivos XML. Essa manipulação faz com que os objetos complexos extraídos sejam então convertidos em tabelas aninhadas, seguindo o mesmo formato adotado no momento da especificação dos objetos de exemplo, e mostrados na janela Extraction Result Window. A Figura 3.5 mostra o resultado da extração no formato de tabelas aninhadas correspondente ao arquivo DTOR referenciado na seção anterior. 3.6 Realimentação de Exemplos na Página de Amostra Como se pode ver na Figura 3.5, alguns objetos complexos do tipo CD Studio não foram completamente extraídos. Isso pode ser percebido através da ausência de alguns valores de `+Wa \ que compõem o objeto representado pela tabela aninhada X+\. Em geral, um objeto só não é recuperado por completo se existe alguma variação estrutural, típica de dados semi-estruturados, na página da Web de amostra ou existe alguma variação no formato HTML das páginas que pode mudar de objeto para objeto. Em ambos os casos, se apenas um objeto de exemplo é fornecido, então apenas os objetos que seguem essa estrutura e esse formato são recuperados, pois os padrões para extração são gerados de acordo com o contexto e estrutura do objeto de exemplo fornecido, como já explicado na Seção Para fazer com que o módulo Extrator recupere também esses objetos que não foram extraídos, o usuário deverá recorrer ao recurso de Realimentação de Exemplos oferecido pela DEByE. Esse recurso é bastante simples de ser usado e se dá da seguinte forma. Analisando o resultado da extração, o usuário poderá fornecer como novo exemplo um dos objetos que não foi completamente extraído. Para isso, basta que o usuário selecione o número da linha da tabela mais externa correspondente ao objeto que não foi extraído. Após a seleção, a seguinte janela (Figura 3.6) aparece automaticamente.

45 3.6 Realimentação de Exemplos na Página de Amostra 31 Figura 3.5: Resultado da extração referente aos objetos de exemplo da Figura 3.4 Essa janela captura a estrutura dos objetos complexos extraídos, ou seja, reflete o número de níveis correspondente a esses objetos. Através dessa janela, o usuário poderá fornecer como novo exemplo qualquer objeto que não foi recuperado, independente do nível a que pertença. Para cada nível de aninhamento existente, o usuário deverá indicar qual a linha que deseja realimentar. Por exemplo, nesse caso em particular, foi escolhida para o primeiro nível de aninhamento a segunda linha correspondente ao artista Vinicius de Moraes e, para o segundo nível de aninhamento, a primeira linha correspondente ao disco A Arca de Noe. Isso pode ser explicado porque, como se pode observar na Figura 3.5, o objeto do tipo `+W a relacionado ao disco \J A Arca de Noe do artista Vinicius de Moraes não foi extraído. Então, decidiu-se por fornecê-lo como novo exemplo. Porém, deve-se observar também que, nesse caso, a caixa relacionada ao terceiro nível de aninhamento não está disponível para seleção, justamente porque a estrutura dos objetos extraídos em questão possui apenas dois níveis. Ao clicar no botão Yes dessa janela, automaticamente os objetos selecionados para serem realimentados são incluídos na janela Example Window e refletidos na Source Window. Isso pode ser visto através da Figura 3.7. A grande vantagem desse recurso é que o usuário só

46 32 Realimentação de Exemplos na DEByE Figura 3.6: Janela utilizada na realimentação dos exemplos precisa preencher a Example Window com os objetos que estão faltando. Isso não será difícil porque a Source Window já posiciona a página de amostra de modo que os objetos não extraídos estejam à vista para o usuário, mostrando exatamente o que é necessário para completar a tabela na Example Window e criar um novo exemplo. No exemplo mostrado, o único objeto a ser preenchido é o preço do disco. Figura 3.7: Tela capturada durante uma sessão de realimentação de exemplos através da DEByE A partir desse momento, o processo de extração pode ser inciado novamente, ou seja, o usuário poderá gerar um novo padrão para extração, agora com dois objetos de exemplo, através do botão Build e, em seguida, executar a extração através do botão Extract. Posteriormente, o usuário poderá avaliar o resultado da extração que estará disponível na janela Extraction Result Window. Esse processo poderá perdurar até que o usuário considere satisfatório o número de objetos extraídos. Nesse momento então, o padrão gerado para esta página de amostra poderá

47 3.7 Realimentação de Exemplos em Outras Páginas do Site 33 ser salvo utilizando o botão Save da janela Extraction Pattern Window e depois usado para realizar a extração em outras páginas da mesma fonte de dados da página de amostra. A Figura 3.8 mostra o resultado da extração após a realimentação do exemplo referente ao artista Vinicius de Moraes. Como se pode ver, todos os objetos que não foram extraídos anteriormente (Figura 3.5) encontram-se presentes no resultado dessa nova extração. Figura 3.8: Resultado da extração referente aos objetos de exemplo da Figura 3.4 Experimentos realizados (Capítulo 4) mostraram que, em situações práticas, poucos objetos de exemplo são suficientes para que praticamente todos os objetos de interesse da página sejam extraídos. 3.7 Realimentação de Exemplos em Outras Páginas do Site É possivel ainda extrair objetos de outras páginas similares, em contexto e estrutura, à página de amostra, como, por exemplo, páginas de um mesmo site ou serviço on-line. Para isso, o usuário

48 34 Realimentação de Exemplos na DEByE abriria uma nova página na Source Window e carregaria, usando o botão Load da Extraction Pattern Window, um OE pattern previamente salvo. Dessa forma, o usuário poderá realizar um novo processo de extração nesta página utilizando o OE pattern carregado. Se o resultado da extração não for satisfatório, o usuário poderá ainda reiniciar todo o processo de realimentação de exemplos novamente e, também, poderá alterar o padrão carregado, adicionando novos e- xemplos através do botão Update da janela Extraction Pattern Window. No entanto, em geral, um OE pattern salvo será usado para extrair automaticamente objetos de um conjunto, possivelmente grande, de novas páginas, similares à página de amostra, fornecidas como entrada para o módulo Extrator. No ambiente DEByE, essas páginas podem ser fornecidas através de um agente gerado pela ferramenta ASByE [25], que poderá operar de forma integrada à ferramenta DEByE. Vale ainda mencionar que se houver alguma modificação nas páginas de um determinado site de seu interesse, o usuário poderá utilizar a interface para fornecer novos exemplos retirados de uma página de amostra modificada e atualizar o OE pattern gerado inicialmente. Esta situação, bastante comum na Web, é tratada de maneira ortogonal no ambiente DEByE. A Figura 3.9 mostra o resultado da extração realizada em uma outra página do mesmo site CD Studio utilizando o padrão salvo que foi gerado para a página de amostra (Figura 2.1) discutida ao londo dessa dissertação. 3.8 Alguns Aspectos da Implementação A ferramenta DEByE, na sua versão atual, foi implementada utilizando duas linguagens de programação, Java [57, 55] e Perl [58]. Para o módulo Interface Gráfica e para o módulo Visualizador, a linguagem Java foi utilizada. Além dessa linguagem, duas bibliotecas adicionais foram utilizadas nesses módulos, a JFC (Java Foundatio Classes) [56, 54], também conhecida pelo nome de Swing e a DOM (Document Object Model) [60] que é uma biblioteca para manipulação de arquivos que seguem o formato XML [10]. O módulo Extrator, por sua vez, foi implementado em Perl. A comunicação entre esses três módulos se dá através de um recurso chamado CGI (Common Gateway Interface) [26].

49 3.8 Alguns Aspectos da Implementação 35 Figura 3.9: Resultado da extração referente ao padrão salvo para a FDW CD Studio

50 36 Realimentação de Exemplos na DEByE

51 Capítulo 4 Experimentos Realizados 4.1 Introdução Neste capítulo são apresentados os resultados obtidos através da análise e experimentação da ferramenta DEByE utilizando o processo de Realimentação de Exemplos. A Seção 4.2 caracteriza os objetivos que se pretende alcançar através do uso desse processo de Realimentação de Exemplos na extração dos dados de FDW (Fontes de Dados da Web). A Seção 4.3 descreve como o experimento foi realizado, quais as FDW utilizadas e suas principais características. Os resultados obtidos mostrando que o processo de Realimentação de Exemplos melhora significativamente a extração dos dados dessas fontes são mostrados na Seção 4.5. Por fim, a Seção 4.6 analisa os resultados obtidos com o experimento e apresenta algumas conclusões sobre os mesmos. 4.2 Objetivos do Experimento Conforme mencionado, experimentos realizados [49] anteirormente com a ferramenta DEByE indicaram que se o usuário visualizasse o resultado da extração, o mesmo poderia detectar prováveis erros cometidos na especificação dos objetos de exemplo e em seguida corrigí-los. Esses erros poderiam ser um não reconhecimento da estrutura dos dados presentes na FDW, ou ainda, não reconhecer mais de uma estrutura na mesma fonte de dados e também, não perceber que muitas vezes são necessários mais de um objeto de exemplo para conseguir obter um bom resultado na extração. Sendo assim, o objetivo desse experimento é validar o processo de Realimentação de Exemplos introduzido através do módulo Visualizador. Com esse módulo, o usuário pode analisar o resultado da extração e, se detectar algum erro, pode realimentar a ferramenta com novos exemplos e iniciar a extração dos dados novamente. O mais importante desse experimento foi avaliar a melhoria proporcionada pela nova estratégia, ou seja, verificar se os objetos que não 37

52 T T 38 Experimentos Realizados foram extraídos na primeira fase da extração, foram efetivamente recuperados após o usuário utilizar a Realimentação de Exemplos. 4.3 Descrição do Experimento O experimento foi realizado em 9 Fontes de Dados da Web. Todas essas fontes podem ser consideradas fontes de dados semi-estruturados e se caracterizam como fontes ricas em dados e de abrangência semântica limitada, isto é, versam sobre assuntos bastante específicos. Essas fontes foram classificadas em três grupos distintos. No primeiro grupo, estão as fontes que possuem objetos cujas estruturas possuem somente um nível de hierarquia. Os sites [15], O6 [50], "!$# % &6'rr>9, [17], -.0/1' 32ò&^' 5 [42] e 798:<;= [40] compõem esse grupo. As fontes que apresentam objetos com estruturas de dois níveis de hierarquia fazem parte do segundo grupo. Os sites representantes desse grupo são DB&LP Index to ACM Transactions on Database Systems (#" :ED3F8 ) [36] e B8 M/1 [16]. Para o terceiro grupo, foram reunidas fontes cujos objetos possuem estruturas de três níveis hierárquicos. Fazem parte desse grupo os sites 24 K MÍ%6Jn ' &6 [18] e?>a@ = -! M ÚP?=?> -.n '( M/o [37]. O experimento se dividiu nas seguintes três etapas: Primeira Etapa Nessa etapa, para cada FDW, foi escolhido uma página de amostra, especificado um determinado objeto de exemplo para esta página, gerado seu respectivo padrão para extração e em seguida realizado a extração propriamente dita dos dados. Segunda Etapa Nessa etapa, o resultado da extração efetuada na etapa anterior foi analisado e os objetos não completamente recuperados foram realimentados, sendo a extração realizada novamente até que se pôde gerar um padrão que extraísse todos os objetos da página de amostra. Quando o resultado da extração se mostrou satisfatório, o padrão gerado para essa página foi gravado, para ser então usado na terceira etapa do experimento. Uma observação a ser feita nessa etapa é que a realimentação dos exemplos se deu considerando o pior caso, ou seja, só foi fornecido um único objeto de exemplo por realimentação. Essa consideração é importante porque se tratando de usuários mais experientes da Web, ao analisar o resultado da extração, esses poderiam perceber quais objetos de exemplo possuem uma influência significativa na geração dos padrões para a extração e realimentá-los todos de uma só vez. Assim, esses usuários conseguiriam realizar a extração em páginas de estrutura bastante complexa, como algumas mostradas na seção seguinte, com apenas uma única realimentação, distanciando muito dos resultados alcançados pelos experimentos.

53 T 4.4 Fontes de Dados Utilizadas no Experimento 39 Terceira Etapa Nessa etapa, foi realizada a extração em inúmeras outras páginas dos sites escolhidos, utilizando os padrões que foram gerados para a página de amostra de cada site. A seguir, o resultado da extração nessas páginas foi analisado. Assim, pôde ser verificado a efetividade da realimentação na geração dos padrões para as páginas de amostra. Outra observação importante dessa etapa é que, se um padrão é gerado para uma página de amostra de um determinado site e as páginas desse site sofrem alguma alteração na estrutura, então o resultado da extração não deve se mostrar da forma como previsto antes dessa mudança. Sendo assim, verificou-se também nessa etapa se o processo de realimentação realmente consegue otimizar o resultado da extração nesses casos. 4.4 Fontes de Dados Utilizadas no Experimento Para descrever a estrutura dos objetos fornecidos como exemplo nas fontes de dados em questão, será utilizada a notação descrita na Seção 2.2 para definição de tipos de objetos. Q! Este site de venda de discos é um dos mais populares na categoria music presente na lista dos sites mais visitados da Web (100Hot Web Site) [1]. A estrutura dessa fonte de dados é bastante simples e homogênea, sem a ausência de nenhum componente como se pode ver na Figura 4.1(a). Os objetos de exemplo dessa fonte foram estruturados da seguinte forma #"%$L# ns/ O& :Q/ *K '&t- L/ ' '&t / y'(( ^*). Segundo a lista do 100Hot Web Site, o site Monster.com é o mais popular na categoria Job. Como se pode ver na Figura 4.1(b), a estrutura dessa fonte se apresenta de forma flat e também homogênea e foi modelada como + ),"%$yf&'&n=6 ' &s/ -& :Q/ *K.& 90/216& 43').! #H% &'(*) +,. Este site da Web apresenta informações sobre a geografia, população, economia, governo de mais de 100 países. Todas essas informações estão organizadas em uma única página por país como mostrado na Figura 4.2(a). Justamente por isto, só pôde fornecer um único objeto de exemplo por página como se pode ver a seguir na Tabela 4.1. Como são muitos os dados disponíveis para cada país, escolheu-se apenas alguns deles que foram estruturadas como ( ^*53,"6$m&-/<.&t= +'&^s/1-& :/< ^ :;3:1 '&t"6)^ <-66 6& K=). - L/ ' ø2ò&^' 5, O site -.0/1' 2ò&^' 5 provê informação sobre preços de computadores e peças para computadores de diversos fornecedores. A Figura 4.2(b) mostra um extrato da página de amostra usada nos experimentos. Os objetos de exemplo dessa págna seguem a estrutura!1'/>"%$m>ö& M?&t- N+M@'(& " O' 0/A1^s/ -&t- L/ ' '&t" &JK & 8 O&^4).

54 b b 40 Experimentos Realizados (a) CDNow 798: ; =( (b) Monster Figura 4.1: Extrato das páginas de amostra da e O6 O site 798: ; = (Networked Computer Science Technical Reference Library) é uma biblioteca digital muito pouplar que contém relatórios técnicos, de instituições de vários lugares do mundo, na área de Ciência da Computação. Como mostrado na Figura 4.2(c), cada relatório possui um título, um ou mais autores, um identificador, o nome da instituição na qual foi pubicado e a data de publicação. A estrutura dos objetos dessta página pode ser definida por ;['1 nb"6$ :Q/ *K '& # ^*5JC&t"+'':/< ^! M?&t! Os/ ^s/1-& F&). 8 M/? O site 8 M/1 é uma loja virtual de venda de discos cuja página de amostra pode ser vista na Figura 2.1. Esta fonte de dados foi utilizada como exemplo ao longo de toda a discussão deste trabalho, e se difere das demais mostradas até agora porque apresenta uma estrutura de dois níveis de aninhamento. Os objetos de exemplo fornecidos para os experimentos seguem a estrutura #"6$ # ts/1o&,& /1O'?"6$ :Q/ -.n ' :)}d'). #" :ED3F8D Essa fonte de dados representa as páginas coletadas do site DB&LP referentes ao periódico Transactions on Database Systems da ACM. Um extrato de uma dessas páginas pode ser visto na Figura 4.3(a). Os objetos de exemplo identificados nas páginas dessa fonte seguem a estrutura :ED3F8D"6$LP.KE:/<.&[ :/ ) 6&,F[ & & # ns/ ' K G"6$ #H^*5 & :Q/ *K '&t-z&i (J)*d'). Assim como a fonte anterior, esta também se carateriza por ser um pouco mais complexa e apresentar mais de um nível de hierarquia.

55 b b b b b 4.4 Fontes de Dados Utilizadas no Experimento 41 (a) CIA Factbook (b) Price Watch (b) NCSTRL Figura 4.2: Extrato das páginas de amostra dos sites "!$#% &'(*) +,, -.0/1'(324&'65, e 798:<;= 424 K MÉ% N('&OB Esse site é um dos mais populares na categoria news segundo o 100Hot Web site. Para cada cidade, o site contém informação sobre as condições climáticas agrupadas pelos dias da semana. A estrutura dos objetos de exemplo desse site é dada pelo tipo %6 N ' &6B"6$O./ K3 & 24 6, F&B3,"%$yF&L3 & :Q/A/< 9M/ s/1-& :9I/21 Ö&^ N."%$*M7/ 5-&n=6N)*d'). Um extrato da página de amostra utilizada no experimento pode ser visto na Figura 4.3(b). P?=+?>O O site DB&LP contém informação sobre os proceedings de várias conferências entre eles os da Very Large Database Conference. Analisando a Figura 4.3(c), pode-se perceber que a estrutura das páginas desse site se mostra bastante complexa apresentando três níveis de hierarquia, assim como as páginas da Gø24 K M %6Jn ' &6B Estruturou-se os objetos de exemplo dessa fonte como - N+' (M/ L"6$KF[& C&t- K1&' '& 8 '(s/,"6$m&:/<.& # ns/ ' K."%$L:?/ *K '& #H^*5 Ld-&t-h& (J)*d')}d').

56 42 Experimentos Realizados (a) ACM TODS (b) CNN World Forecast (c) VLDB Figura 4.3: Extratos das páginas de amostra dos -4#" :ED3F8, G 24 LK M %6 NBP '&O e?>a@=+-pq=?> 4.5 Resultados Obtidos A avaliação dos resultados obtidos envolveu basicamente duas etapas. Uma relacionada com a extração dos dados na página de amostra de uma determinada fonte e a segunda relacionada com a extração em outras páginas dessa mesma fonte. Primeiramente, foi verificado se o processo de realimentação de exemplos ajudou o usuário a gerar um padrão para extração que recuperasse completamente todos os objetos da página de amostra. Nesse caso, a intenção era que, em páginas mais complexas, o usuário pudesse perceber através da visualização do resultado da extração que a fonte em questão possuía certas irregularidades na estrutura dos seus dados ou diferenças existentes entre instâncias distintas e até mesmo diferenças na formatação da página e, baseado nessas percepções, se o processo de