recuperação de informação integrada ao banco de dados xml

UNIVERSIDADE FEDERAL DO RIO GRANDE DO SUL

INSTITUTO DE INFORMÁTICA

CURSO DE CIÊNCIA DA COMPUTAÇÃO

LUIZ HERMES SVOBODA JUNIOR

Recuperação de Informação Integrada ao Banco de Dados XML Nativo - XTC

Trabalho de Graduação Profa. Dra. Renata de Matos Galante Orientadora Msc. Leonardo Ribeiro Co-orientador Databases and Information Systems (AG DBIS) at University of Kaiserslautern

Porto Alegre, junho de 2008.

2

UNIVERSIDADE FEDERAL DO RIO GRANDE DO SUL Reitor: Prof. José Carlos Ferraz Hennemann Vice-reitor: Prof. Pedro Cezar Dutra Fonseca Pró-Reitor de Graduação: Prof. Carlos Alexandre Netto Diretor do Instituto de Informática: Prof. Flávio Rech Wagner Coordenador do CIC: Prof. Raul Fernando Weber Bibliotecária-Chefe: Beatriz Regina Bastos Haro

3

AGRADECIMENTOS

Primeiramente gostaria de agradecer à minha família. Aos meus pais,

Luiz Hermes Svoboda e Liane Camargo Svoboda, por estarem sempre ao meu lado, me apoiando em todas as minhas decisões e pela compreensão durante este período de estudos no qual estive ausente em muitos momentos por motivo de provas ou trabalhos do curso. Às minhas irmãs, Carla Svoboda e Aline Svoboda, pelos poucos, porém ótimos momentos no qual tivemos a oportunidade de estarmos todos reunidos.

Gostaria de agradecer ao meu amigo Marcus Lucas da Silva por ter sido a pessoa que mais me motivou pela escolha do curso de Ciência da Computação. Gostaria de agradecer ao meu amigo Vinícius Lucas da Silva pelos momentos de descontração. Além de grandes amigos, considero estas duas pessoas como meus irmãos.

Gostaria de agradecer à Profa. Dra. Mara Abel, minha orientadora durante o período de Iniciação Científica, pelo apoio e estímulo para o meu desenvolvimento no meio acadêmico. Aos amigos do Grupo BDI pela constante troca de conhecimento durante o período no qual tive a oportunidade de desenvolver um trabalho de pesquisa juntamente com eles. Ao MSc. Felipe Victoreti pelo apoio e motivação recebidos tanto durante meu período de bolsista como pela oportunidade de ser um dos colabores da ENDEEPER, empresa da qual ele é um dos sócios.

Gostaria de agradecer ao Prof. Dr.-Ing. Dr. h. c. Theo Härder pela oportunidade de realização de parte dos meus estudos na Universidade Técnica de Kaiserslautern na Alemanha. A todos os integrantes do Grupo de Banco de Dados e Sistemas de Informação, grupo no qual desenvolvi atividades de pesquisa durante os estudos na Alemanha. Ao MSc. Leonardo Ribeiro por ser meu co-orientador neste trabalho.

Gostaria de agradecer aos colegas Leonardo Dalpiaz, Gustavo Machado, José Irigon, José Rodrigo Azambuja, Lúcio Rech e David Nemer. Tive a oportunidade de conhecê-los durante o período de estudos na Alemanha e espero contar com a amizade destas pessoas por muito tempo.

Gostaria de agradecer à minha orientadora, a Profa. Dra. Renata de Matos Galante pelo apoio recebido durante o desenvolvimento deste trabalho.

4

SUMÁRIO

AGRADECIMENTOS ......................................................................................... 3

SUMÁRIO .......................................................................................................... 4

LISTA DE ABREVIATURAS E SIGLAS ............................................................ 6

LISTA DE FIGURAS .......................................................................................... 7

LISTA DE TABELAS ......................................................................................... 8

RESUMO ............................................................................................................ 9

ABSTRACT ...................................................................................................... 10

1. INTRODUÇÃO .......................................................................................... 11

2. XML TRANSACTION MANAGER (XTC) .................................................. 14

2.1. BANCO DE DADOS XML NATIVO ............................................................. 14 2.2. PROJETO XTC ...................................................................................... 15

2.2.1. DeweyID ....................................................................................... 16 2.3. EXTENSIBLE MARKUP LANGUAGE (XML) ................................................. 17

2.3.1. Estrutura ....................................................................................... 18 2.4. CONSIDERAÇÕES FINAIS ........................................................................ 19

3. RECUPERAÇÃO DE INFORMAÇÃO ....................................................... 20

3.1. RECUPERAÇÃO DE INFORMAÇÃO VERSUS RECUPERAÇÃO DE DADOS ......... 21

3.2. RECUPERAÇÃO AD HOC E FILTERING ........................................................ 21 3.3. MODELOS DE RECUPERAÇÃO DE INFORMAÇÃO ......................................... 22

3.3.1. Caracterização Formal de um Modelo de IR ................................ 22 3.3.2. Modelo Booleano .......................................................................... 22 3.3.3. Modelo Vetorial ............................................................................. 23 3.3.4. Modelo Probabilístico ................................................................... 24 3.3.5. Considerações sobre os modelos de IR ....................................... 25

3.4. O PROCESSO DE RECUPERAÇÃO DE INFORMAÇÃO ................................... 25 3.5. AVALIAÇÃO DE MECANISMOS DE IR ......................................................... 27 3.6. CONSIDERAÇÕES FINAIS ........................................................................ 27

4. PREPARAÇÃO DO DOCUMENTO ........................................................... 28

4.1. INDEXAÇÃO DO DOCUMENTO .................................................................. 28 4.2. ANÁLISE DO TEXTO ................................................................................ 29

4.2.1. Análise Léxica ............................................................................... 29 4.2.2. Eliminação de Stopwords ............................................................. 30 4.2.3. Stemming...................................................................................... 30

5

4.3. TÉCNICAS DE INDEXAÇÃO ....................................................................... 31 4.3.1. Árvore de Sufixos (Suffix Tree) ..................................................... 31 4.3.2. Arquivo de Assinatura (Signature File) ......................................... 31 4.3.3. Arquivo Invertido (Inverted File) .................................................... 32

4.4. ESTRUTURAS DE ÍNDICE PARA DOCUMENTOS XML .................................... 33

4.5. CONSIDERAÇÕES FINAIS ........................................................................ 34

5. RECUPERAÇÃO DE INFORMAÇÃO INTEGRADA AO BANCO DE DADOS XTC .................................................................................................... 35

5.1. MODELO DE RECUPERAÇÃO DE INFORMAÇÃO........................................... 35 5.2. ÍNDICE .................................................................................................. 36

5.2.1. Registro ........................................................................................ 36 5.2.2. Construção do Índice .................................................................... 37

5.3. CONSULTA ............................................................................................ 38 5.3.1. Linguagem de Consulta ................................................................ 39

5.4. PROCESSAMENTO DA CONSULTA ............................................................ 41

5.4.1. Estrutura ....................................................................................... 41 5.4.2. Conteúdo ...................................................................................... 44

5.5. CLASSIFICAÇÃO DOS RESULTADOS (RANKING) ......................................... 45 5.6. AVALIAÇÃO DO MECANISMO DE IR ........................................................... 46

5.6.1. Geração de Índices ....................................................................... 46 5.6.2. Recuperação de Informação......................................................... 48

6. CONCLUSÃO ............................................................................................ 52

6.1. TRABALHOS FUTUROS ............................................................................ 53

REFERÊNCIAS ................................................................................................ 56

ANEXO 1 – IMPLEMENTAÇÃO DO MECANISMO ........................................ 58

A.1 DIAGRAMAS DE CLASSE .......................................................................... 58

6

LISTA DE ABREVIATURAS E SIGLAS

IR Information Retrieval

XML Extensible Markup Language

SGML Standart Generalized Markup Language

XTC XML Transaction Coordinator

API Application Programming Interface

XDBMS XML Database Management System

CAS Content and Structure

CO Content Only

ANTLR Another Tool for Language Recognition

SAX Simple API for XML

DOM Document Object Model

INEX Initiative for the Evaluation of XML Retrieval

W3C World Wide Web Consortium

XISS XML Indexing and Storage System

XICS XML Indices for Content and Structural Search

TF-IDF Term Frequency – Inverse Document Frequency

XDBMS XML Database Management System

MAP Mean Average Precision

7

LISTA DE FIGURAS

Figura 2.1 – Arquitetura do XDBMS XTC ......................................................... 16 Figura 2.2 – (a) Documento exemplo (b) Representação do documento utilizando XML .................................................................................................. 18 Figura 3.1 – Termos, documentos e a matriz termos x documentos ................ 23 Figura 3.2 – Exemplo de mecanismo para cálculo do peso ............................. 24 Figura 3.3 – Mecanismo de recuperação de informação ................................. 26 Figura 4.1 – Descrição do processo de indexação ........................................... 28

Figura 4.2 – (a) Árvore de sufixos para o texto de exemplo (b) Array de sufixos para o texto de exemplo ................................................................................... 31 Figura 4.3 – Texto de exemplo com os blocos e o vetor de bits associado à cada um deles .................................................................................................. 32 Figura 4.4 – Texto exemplo e a lista invertida para o texto .............................. 32 Figura 4.5 – Representação em árvore de um documento XML ...................... 33 Figura 4.6 – (a) Índice STB-Tree para o documento de exemplo (b) representação parcial do índice COB-Tree para o documento de exemplo ..... 34 Figura 5.1 – Representação em árvore de um documento XML ...................... 41 Figura 5.2 – Resultado da pesquisa para o termos author no dicionário WordNet ........................................................................................................... 43 Figura 5.3 – Tamanhos dos documentos e índices .......................................... 47 Figura 5.4 – Tempo para criação dos índices .................................................. 48 Figura 5.5 – (a) Gráfico revocação versus precisão para a consulta Q1 (b) Gráfico revocação versus precisão para a consulta Q2 .................................... 50

8

LISTA DE TABELAS

Tabela 2.1 – Nodos resultantes para o documento tomado como exemplo ..... 17 Tabela 5.1 – regras da linguagem de consulta MicroXPath ............................. 40 Tabela 5.2 – consultas de exemplo e nodos recuperados para cada consulta 40 Tabela 5.3 – Exemplo de consulta com o construto estrutura, conjunto de sinônimos retornados e o conjunto de caminhos expandidos .......................... 43 Tabela 5.4 – Exemplos de mapeamento de nome de tag para identificador .... 44 Tabela 5.5 – Dados dos documentos da coleção ............................................. 47

Tabela 5.6 – Dados sobre os índices gerados para a coleção ......................... 47 Tabela 5.7 – Informações da coleção de documentos ..................................... 49 Tabela 5.8 – Consultas executadas no documento SigmodRecord.xml .......... 49 Tabela 5.9 – Consultas executadas no documento Collection.xml .................. 49 Tabela 5.10 – Valores de MAP e revocação para o primeiro conjunto de consultas .......................................................................................................... 50 Tabela 5.11 – Resultados para as consultas avaliadas ................................... 51

9

RESUMO

Durante os ultimo anos, houve um crescimento no número de repositórios de informação armazenada no formato XML. Como o tamanho dos documentos no formato XML tende a ser muito grande, existe um crescente esforço no desenvolvimento de mecanismos de recuperação de informação em documentos XML com o objetivo de suportar recuperação de elementos dos documentos. Esta estratégia de recuperação é muito útil considerando a presença de grandes documentos ou um grande número de documentos. A recuperação de elementos do documento é alcançada explorando a informação estrutural contida nos documentos no formato XML. Nesta situação, surge um problema considerando que existe uma grande quantidade de documentos XML que descrevem um conteúdo similar, porém utilizando diferentes estruturas e diferentes nomes de tag.

Neste trabalho é apresentada uma proposta de mecanismo de recuperação de informação integrado ao gerenciador de banco de dados XML nativo XTC. O presente trabalho faz uso da informação estrutural fornecida pelo esquema de rotulação de nodos empregado pelo sistema XTC que identifica univocamente cada um dos elementos do documento. Para resolver o problema considerando as diferentes estruturas e diferentes nomes de tag, o mecanismo de recuperação de informação expande o construto estrutural através da substituição dos nomes de tag por nomes similares através da utilização de uma ontologia.

Palavras-Chave: recuperação de informação, XML.

10

ABSTRACT

For the past several years, there was a continuous growth in XML information repositories. As XML documents tend to be very large, there is an increasing effort in the development of XML retrieval mechanisms aiming at supporting content-oriented XML retrieval. This retrieval approach is very useful when considering large documents or a large number of documents since it retrieves the most important fragments of these documents. The retrieval task is accomplished by exploiting the structural information available in XML documents. This scenario raises the issue that there is a large amount of XML data in which similar contents are described using different tag names and structures.

In this project, a proposal of a content-oriented information retrieval mechanism integrated to the XML native data base management system XTC is presented. The proposal makes use of the structural information provided by the node labeling scheme used by the XTC database to uniquely identify each element of the document. To cope with the issue of different tag names and structures, the mechanism expands the structural constraints defined in the query by replacing tag names with similar ones with the help of ontologies.

Key-Words: information retrieval, XML.

11

1. INTRODUÇÃO

Recuperação de informação é a ciência que lida com a busca por informação. O objetivo de um mecanismo de IR não é recuperar apenas informação que casa exatamente com a consulta realizada. Ao contrário da recuperação de dados, IR também tem como objetivo retornar informação sobre o tópico ou assunto consultado. Desta forma, uma ferramenta que se proponha a realizar a tarefa de IR, deve recuperar informação que de alguma forma possa ser útil para satisfazer a necessidade de informação do usuário, mesmo que o conjunto de documentos retornados contenha alguns erros.

Por vários anos, as pessoas têm percebido a importância de armazenar e de buscar informação. Com o advento dos computadores, tornou-se possível o armazenamento de quantidades de dados nunca antes vistas. Encontrar e recuperar informações úteis de tais quantidades de dados tornou-se uma tarefa cada vez mais difícil. Por esta razão, muitas universidades, bibliotecas e até mesmo grandes companhias utilizam mecanismos de IR para prover acesso a livros, jornais e qualquer outro tipo de documento. Ferramentas de busca na web como Google1 e Yahoo2 também fazem uso de sistemas de IR e estas são, sem dúvida, as aplicações mais visíveis deste tipo de mecanismo.

Neste contexto, XML tem tido um papel muito importante. XML é um subconjunto de SGML e pode ser vista como uma linguagem de propósito geral para descrição de dados semi-estruturados. Esta linguagem foi desenvolvida para ser de fácil entendimento tanto por pessoas como por máquinas. XML é chamada de extensível por permitir ao usuário definir as suas próprias tags e associar informação estrutural, ou informação semântica, aos dados que estão contidos no arquivo. Originalmente criada para facilitar o compartilhamento de dados semi-estruturados entre diferentes plataformas, particularmente pela Internet, XML tem sido freqüentemente utilizada para a representação de informação. Pode-se dizer que, atualmente, praticamente em todos os lugares onde há informação, XML também está presente. Como resultado disso, XML vem crescendo como um grande tópico e tem inspirado o desenvolvimento de muitas tecnologias e pesquisas nesta área.

O contínuo crescimento nos repositórios de dados que utilizam XML acaba casando com o crescente esforço para desenvolvimento de ferramentas para a realização de consultas sobre estes dados. Algumas destas ferramentas oferecem apenas o recurso de busca sobre os documentos enquanto outras, mais sofisticadas, provêem uma forma de armazenamento mais adequada para

1 http://www.google.com 2 http://www.yahoo.com

12

este tipo de documento. Como exemplo de mecanismos simples para indexação e consulta a coleções de documentos em geral, citamos o projeto Lucene3 o aplicativo Zebra4. Em relação aos aplicativos que se propõe a oferecer um meio de armazenamento e consulta mais adequados a arquivos XML, os chamados bancos de dados XML nativos, podemos citar o BaseX5, o eXist6 e o Sedna7.

Com a grande utilização de XML em bibliotecas digitais, catálogo de produtos, repositórios de dados científicos, etc., tornou-se uma necessidade o desenvolvimento mecanismos mais adequados para realizar pesquisas em documentos XML. Neste sentido, recuperação de informação em arquivos XML é uma nova área na aplicação de métodos de IR. Embora pouca pesquisa tenha sido feito no passado a respeito de recuperação de informação em dados semi-estruturados, a crescente disponibilidade de coleções no formato XML oferece uma grande oportunidade de desenvolvimento de métodos de recuperação mais apropriados.

Este trabalho está no escopo de um projeto maior chamado XTC Project. XTC é um protótipo de gerenciador de banco de dados XML nativo que tem como objetivo permitir o processamento de documentos XML em um ambiente multiusuário fazendo uso de APIs típicas para XML como DOM, SAX, XPath, provendo um modelo adequado para o armazenamento de dados no formato XML. Neste trabalho será proposto um mecanismo de recuperação de informação integrado ao sistema XTC. Este mecanismo tem como objetivo proporcionar ao usuário uma maneira de recuperar elementos de documentos XML, os quais venham a ser considerados relevantes em relação à consulta submetida, sob o julgamento da ferramenta. Como mencionado anteriormente, houve um crescimento muito grande na utilização de XML nos repositórios de informação. Este crescimento não está apenas relacionado ao número de arquivos, mas também ao tamanho destes arquivos. Este modelo de recuperação de elementos do documento visa facilitar a tarefa do usuário de percorrer os resultados. Desta forma, o usuário recebe como resultado apenas os elementos relevantes evitando assim a necessidade de percorrer o documento completo à procura do(s) elemento(s) que contém a informação consultada.

Para o desenvolvimento deste mecanismo, serão feitas análises acerca dos modelos de IR clássicos e sobre todo o processo que envolve a tarefa de recuperação de informação neste tipo de documento. Desta forma, é proposta a utilização de técnicas de indexação de arquivos XML a fim de acelerar o processo de busca, evitando a necessidade do percorrimento do arquivo a cada consulta submetida. Finalmente, é apresentado o modelo de ordenamento dos resultados recuperados de acordo com medidas pré-estabelecidas no mecanismo.

3 http://lucene.apache.org/ 4 http://www.indexdata.dk/zebra/ 5 http://www.basex.org/ 6 http://exist.sourceforge.net/ 7 http://modis.ispras.ru/sedna/

13

Este trabalho é organizado da seguinte maneira. O capítulo 2 faz uma rápida apresentação sobre o projeto XTC, projeto no qual está trabalho está inserido, e sobre os conceitos de banco de dados XML nativo. Ainda neste capítulo, são introduzidos alguns conceitos relacionados ao formato XML. No capítulo 3 são apresentados os principais conceitos relacionados a IR e os seus modelos clássicos. Da mesma forma, é feita uma discussão sobre o processo de recuperação de informação no qual o autor apresenta, através de um diagrama, a sua visão do processo. Por fim, são discutidas as métricas de avaliação deste tipo de mecanismo. O capítulo 4 introduz os conceitos do processo de preparação dos documentos. Neste sentido, como no capítulo anterior, o autor apresenta um diagrama com a visão do processo de preparação do documento e realiza uma análise das estruturas de dados utilizadas para a indexação de arquivos. Por fim, no capítulo 5 é apresentado o mecanismo de recuperação de informação desenvolvido de maneira integrada ao gerenciador de banco de dados XML nativo XTC. Este mecanismo tem como objetivo prover uma ferramenta básica para IR e sobre a qual possam ser realizados testes e otimizações de técnicas relacionadas a esta área de pesquisa. Ao final do capítulo são apresentados resultados experimentais com o objetivo de comprovar o funcionamento da abordagem proposta.

14

2. XML TRANSACTION MANAGER (XTC)

Neste capítulo será discutido o conceito de banco de dados XML nativo, finalizando esta discussão com uma breve apresentação do projeto XTC. O objetivo consiste em estabelecer as premissas no qual o trabalho proposto está inserido. Também serão apresentados conceitos importantes sobre a tecnologia XML, suas aplicações e as vantagens na sua utilização.

2.1. Banco de Dados XML Nativo

Com a adoção da linguagem XML como padrão para compartilhamento de dados entre diferentes sistemas, houve um rápido e maciço crescimento no seu uso. Formas mais adequadas para armazenar os arquivos disponíveis neste formato têm sido propostas. Grande parte delas propõe uma decomposição do documento, especificado através da linguagem XML, e o posterior armazenamento do resultado deste processo de decomposição em um banco de dados relacional. Porém, existem ainda desafios na utilização desta abordagem de armazenamento. Por exemplo, controlar a ordem dos elementos do documento de maneira prática e eficiente e, outra tarefa importante, fazer a tradução das consultas formuladas através de linguagens de consulta para documentos XML em consultas na linguagem SQL.

Tendo em vista estes e outros fatores que desfavorecem o armazenamento deste tipo de documento na forma mencionada, surgiu a necessidade de formas mais apropriadas para a realização desta tarefa e, o que presenciamos hoje, é o surgimento de gerenciadores de banco de dados que se propõe a armazenar os documentos no seu formato original, ou seja, armazenam diretamente XML.

Bancos de dados XML nativos são banco de dados desenvolvidos especialmente para armazenar documentos XML. Como outros bancos de dados, eles têm suporte a características como transações, acesso multiusuário, segurança entre outras. A grande diferença entre este modelo de banco de dados e os demais é que o seu modelo interno é baseado em XML, diferente de, por exemplo, um modelo relacional.

• Banco de dados XML nativo baseado em texto: é aquele que armazena o documento XML como texto. A maneira mais comum de se armazenar o documento neste formato é através do uso de índices. Através destes índices, um sistema de busca pode facilmente buscar qualquer parte do documento sem precisar realizar o seu percorrimento.

15

• Banco de dados XML nativo baseado em modelo: é aquele que ao invés de armazenarem o documento em índices, o SGBD cria uma estrutura do documento e este modelo que é armazenado. A maneira como esta estrutura é armazenada varia, por exemplo, alguns armazenam o DOM [4] em um banco de dados relacional.

2.2. Projeto XTC

XTC [3] é um banco de dados XML nativo desenvolvido pelo grupo de pesquisa de banco de dados e sistemas de informação da Universidade Técnica de Kaiserslautern. Este projeto é coordenado pelo Prof. Dr.-Ing. Dr. h. c. Theo Härder e pelo estudante de doutorado Dipl. Inf. Christian Mathis. O objetivo deste projeto é explorar e avaliar os aspectos a cerca do armazenamento nativo de documentos XML. Basicamente, o projeto consiste em três protótipos: XTCserver (sistema de gerenciamento de banco de dados XML nativo), XTCclp (um processador de linha de comando baseado em texto) e por fim o XTCcc (centro de controle com uma interface gráfica).

Como mencionado anteriormente, o objetivos principal deste projeto é avaliar aspectos de armazenamento de documentos XML como o processamento de consultas XQuery [8], a utilização de diferentes estruturas de índices, a adoção de APIs XML (SAX [5], DOM [4], XPath [6]) e o controle do isolamento de transações durante o acesso aos documentos armazenados.

O banco de dados XTC emprega uma arquitetura baseada em modelo e utiliza uma variação de árvore DOM como modelo de armazenamento. Esta variação não provoca nenhuma alteração semântica no documento e é empregada apenas por motivos de otimização.

A Figura 2.1 apresenta uma visão geral da arquitetura do gerenciador de banco de dados XTC. Esta arquitetura foi definida com base em um modelo de quatro camadas. A primeira camada é a encarregada pelo gerenciamento dos arquivos físicos nos quais os dados dos documentos XML são armazenados. A segunda camada é responsável pela otimização no acesso aos dados da primeira camada, ou seja, é encarregada do gerenciamento dos buffers de acesso. Nestas duas camadas são empregados mecanismos já desenvolvidos para utilização em bancos de dados relacionais. A terceira camada (Access Services) é encarregada de prover acesso eficiente e realizar o controle de operações concorrentes sobre os documentos XML. Estes dois objetivos são alcançados através da utilização de uma representação interna especializada. Neste sentido, o XTC adota o modelo de armazenamento de árvore taDOM. No modelo taDOM é introduzido um nodo raiz de atributos. Desta forma, os atributos não ficam conectados diretamente ao nodo elemento. Outra melhoria é a inclusão do nodo string. Da mesma forma que o nodo raiz de atributos, a inclusão do nodo string tem como objetivo desvincular a representação de uma string em relação à representação do nodo elemento ao qual a string esta associada. Através destas modificações, é obtido um maior grau de concorrência tendo em vista que operações são realizadas nos nodos mais abaixo da árvore, isto é, o lock é feito apenas no nodo que esta sendo utilizado e não no elemento ao qual ele esta associado.

16

Ainda em relação ao modelo de acesso a nodos da árvore de um documento XML, é necessário destacar a importância de um esquema de rotulação de nodos que identifique cada um dos nodos da árvore, permitindo assim o acesso direto a cada um deles. Neste sentido, o XTC emprega o sistema de rotulação de nodos chamado deweyID (seção 2.2.1). Por fim, a quarta camada (Node Services) é encarregada de fornecer suporte a navegação nos nodos e a avaliação de consultas. Para realização destas tarefas, é utilizado um interpretador de consultas XQuery.

Figura 2.1 – Arquitetura do XDBMS XTC

Mais informações a respeito da arquitetura e do modelo utilizado pelo XDBMS XTC podem ser encontradas em [3].

2.2.1. DeweyID

Os esquemas de rotulação de nodos para documentos XML possuem um papel fundamental no processo de indexação desses arquivos. Esquemas de rotulação têm como objetivo a identificação de todos os nodos de um documento XML permitindo acesso rápido a eles sem a necessidade de percorrimento do documento. Nesta seção faremos a introdução do esquema de rotulação chamado deweyID [13] tendo em vista que este é o esquema utilizado pelo XTC.

2.2.1.1. Fundamentos do esquema de rotulação DeweyID

O elemento raiz de um documento é sempre rotulado com o deweyID “1”. Os filhos recebem o deweyID do seu pai e adicionam mais uma divisão a qual é incrementada seguindo a ordem dos nodos filhos da esquerda para a direita.

17

Existe ainda um conceito de distância que permite inserções de elementos no documento. O parâmetro distância determina o intervalo que será deixado livre para futuras inserções. Por padrão, a distância adotada é dois. Além disso, o primeiro filho acrescenta o valor distância mais um no seu deweyID pois o valor um é reservado para o nodo raiz de atributo. Um elemento que possui pelo menos um atributo, recebe um nodo raiz de atributo com o deweyID estendido por uma divisão com o valor um. O valor de um atributo ou de um nodo que contém texto é armazenado em um nodo texto. O nodo texto recebe o deweyID do pai estendido por uma divisão por um.

Utilizando o arquivo XML exemplo da Figura 2.2 (b) apresentamos uma tabela (Tabela 2.1) com os nodos do esquema deweyID.

Tipo do Nodo DeweyID

bib element 1

book element 1.3

attribute root 1.3.1

id attribute 1.3.1.3

1 string 1.3.1.3.1

title element 1.3.3

text 1.3.3.3

Information ... string 1.3.3.3.1

author element 1.3.5

text 1.3.5.3

Murray Browne string 1.3.5.3.1

Tabela 2.1 – Nodos resultantes para o documento tomado como exemplo

O esquema de rotulação deweyID oferece acesso direto a cada um dos nodos do documento XML sem a necessidade do percurso do documento. Este esquema também permite determinarmos o nível do elemento na árvore de representação. Além disso, podemos derivar todo o path do elemento até a raiz sem a necessidade de acessar o documento. Finalmente, este esquema permite verificarmos facilmente os ancestrais de um nodo. Para verificarmos se o nodo n1 e um ancestral de n2, basta verificarmos se o deweyID do nodo n1 é prefixo do deweyID do nodo n2.

2.3. Extensible Markup Language (XML)

Extensible Markup Language [1,7] é um subtipo de SGML [2]. XML é uma linguagem de marcação de dados, isto é, provê um formato para descrever dados estruturados facilitando declarações mais precisas do conteúdo.

O XML, por ser um subconjunto do SGML, é definido pelo órgão W3C8, fato que assegura a uniformidade dos dados estruturados através desta linguagem, independente de aplicações e/ou fornecedores. Algumas características que foram consideradas durante o processo de desenvolvimento desta linguagem foram:

- Um simples documento de texto;

8 http://www.w3.org

18

- Separação entre conteúdo e estrutura;

- Possibilidade de criação de tags sem limitação;

- Foco na estrutura dos dados e não no conteúdo.

Todos estes fatores tornaram XML a linguagem padrão para compartilhamento de dados, seja na Web, seja entre bases de dados.

2.3.1. Estrutura

A maioria dos documentos (por exemplo, livros ou revistas) pode ser quebrada em componentes (capítulos ou seções). Estes componentes podem também ser divididos em componentes mais específicos, como título, parágrafo, figura e assim por diante.

Em XML, estes componentes são chamados de elementos. Cada elemento representa um componente lógico do documento. Elementos podem conter outros elementos e podem conter também palavras ou frases que seriam o texto contido no documento. A Figura 2.1 mostra esta visão lógica do documento e é conhecida como estrutura em árvore do documento.

Bib: 1: Information Retrieval, Murray Browne. Price: Unavailable.

(a)

<?xml version=“1.0”?>

<bib>

<book id=“1”>

<title>Information Retrieval</title>

<author> Murray Browne</author>

<price/>

</book>

</bib>

(b)

Figura 2.2 – (a) Documento exemplo (b) Representação do documento utilizando XML

O elemento que contêm todos os outros é chamado elemento raiz, que também pode ser chamado de elemento documento tendo em vista que toda a estrutura lógica do documento esta contida nele. Os elementos internos a este elemento raiz são chamados subelementos e estes por sua vez, podem possuir elementos internos a eles e assim por diante.

Elementos podem ter ainda informações extras associadas a ele chamadas atributos. Atributos descrevem propriedades daquele elemento. Apesar de alguns elementos não servirem perfeitamente neste modelo em árvore, a grande maioria pode ser representada através de um documento XML.

Aplicações a serem destacadas em relação à tecnologia XML:

• Buscas mais eficientes: é possível utilizar a informação estrutural de um arquivo XML na especificação de uma consulta sobre este arquivo. Por exemplo, uma busca por um determinado autor poderia levar a resultados onde apenas o nome especificado consta, enquanto que através do XML seria possível especificar a estrutura com a qual o nome deve estar relacionado.

19

• Integração de dados: o processo de integração de dados pode ser facilmente realizado à medida que os dados a serem integrados sigam a mesma especificação. Por exemplo, a realização de uma consulta em diferentes bases de dados torna-se possível através da conversão dos dados armazenados em cada uma das bases para o formato XML e posteriormente, via software, seria realizada a integração destes dados.

• Atualização granular de documentos: os dados contidos em um documento podem ser alterados de maneira granular, ou seja, sem a necessidade de que uma alteração cause a busca pelo documento inteiro. Da mesma forma, novos dados podem ser inseridos sem a necessidade de reconstrução do documento inteiro.

• Múltiplas formas de visualização: uma vez que o XML define apenas os dados e a sua estrutura, a interpretação visual dos dados contidos no documento pode ser realizada de diversas maneiras de acordo com a aplicação.

2.4. Considerações Finais

Neste capítulo foi apresentado o projeto XTC, projeto no qual este trabalho esta inserido. Da mesma forma, foram discutidas características relevantes em relação ao gerenciador de banco de dados XTC no contexto do desenvolvimento e integração de um mecanismo de IR para este sistema.

Também foi realizada uma introdução à tecnologia XML e sua aplicabilidade. Pontos importantes que motivaram a difusão e adoção desta tecnologia padrão para compartilhamento de dados entre outras utilidades também foram discutidos.

20

3. RECUPERAÇÃO DE INFORMAÇÃO

Neste capítulo serão apresentados os modelos clássicos de IR, descrevendo um pouco o funcionamento e as características que definem cada um. Ao final do capítulo, sob o ponto de vista do autor, é descrito o processo de IR e é mostrada uma arquitetura para este tipo de sistema. Iniciaremos este capítulo com um breve esclarecimento entre os conceitos de recuperação de informação e recuperação de dados.

Recuperação de Informação [14] pode ser definida como a ciência que trabalha com a busca por informação. Recuperação de Informação trata com a representação, o armazenamento, a organização e o acesso à informação. Essas características devem prover ao mecanismo de recuperação acesso fácil à informação na qual o usuário está interessado.

Um processo de IR começa com a submissão de uma requisição de informação pelo usuário. Esta consulta não identifica unicamente um objeto da coleção sobre a qual ela foi submetida. Ao contrário, vários objetos da coleção podem casar com a consulta, no entanto, com diferentes graus de relevância.

Sistemas tradicionais de IR usualmente adotam uma estrutura de índices os quais armazenam os dados contidos nos objetos da coleção. Modelos clássicos consideram que cada documento é descrito por um conjunto de palavras representativas. Estas palavras representam o conteúdo descrito no documento e são utilizadas na construção de um índice. De uma forma geral, um termo representativo é uma palavra que aparece no texto de um documento e que possui um sentido por si só.

Recuperação de informação baseada em termos representativos é relativamente simples, porém assume que o texto e a consulta do usuário possam ser expressos como um conjunto de termos. Claramente percebe-se que este fato é uma simplificação do problema, pois se corre o risco de perder parte da semântica do documento ou da consulta do usuário no momento que é feita esta substituição por um conjunto de termos.

Pode-se dizer que a tarefa mais importante de um mecanismo de IR é a capacidade de classificar os documentos como relevantes ou irrelevantes de acordo com a consulta do usuário. Esta decisão é usualmente feita pelo algoritmo de ranking o qual estabelece uma ordem entre os objetos retornados. Os objetos que estão no topo são considerados mais relevantes. Este algoritmo de ranking opera de acordo com um conjunto de premissas que descreve a noção de relevância adotada pelo sistema.

21

3.1. Recuperação de Informação versus Recuperação de Dados

No contexto de IR, recuperação de dados consiste principalmente na determinação de quais documentos, dentre os presentes em uma coleção, satisfazem a necessidade de informação do usuário. Isto é, em recuperação de dados, basta que o documento contenha os termos que o usuário definiu na consulta. Muito freqüentemente, este fato não é suficiente para que um documento possa ser considerado relevante e que satisfaça a necessidade de informação do usuário.

O usuário de um mecanismo de IR está mais interessado na recuperação de informação sobre um determinado assunto do que na recuperação de dados que satisfazem uma determinada consulta. Um mecanismo de recuperação de dados tem como objetivo retornar todos os objetos que satisfazem claramente uma determinada condição, pois trabalha com dados que possuem uma estrutura e uma semântica bem definida. Desta forma, se existir apenas um objeto errado no conjunto de objetos retornados, isto significaria falha total para este sistema.

Entretanto, para um mecanismo de IR, os objetos retornados podem ser inexatos, isto é, podem conter pequenos erros. A eficiência de um mecanismo de IR esta na sua capacidade de “interpretar” o documento analisado. Esta “interpretação” de um documento envolve extrair informações relativas ao seu conteúdo e à sua estrutura e utilizar esta informação para comparação com a consulta realizada pelo usuário. A dificuldade neste processo não esta em apenas realizar o processo de interpretação do documento, mas também em utilizar esta informação para determinar se um documento é relevante ou não de acordo com a consulta realizada. Sendo assim, um conceito fundamental em IR é a relevância. Desta forma, pode-se entender que o objetivo de um sistema de IR é retornar todos os documentos considerados relevantes mesmo que no conjunto de objetos retornados, existam alguns irrelevantes.

3.2. Recuperação ad hoc e filtering

Em mecanismos de IR convencionais, os documentos da coleção permanecem de certa forma inalterados enquanto novas consultas são submetidas ao sistema. Este modo de operação é chamado ad hoc e é a forma mais comum para o usuário prover a sua necessidade de informação.

Outro modo de funcionamento é chamado filtering no qual a consulta permanece relativamente inalterada enquanto os documentos vão chegando ao sistema (e são eliminados após análise). Neste último modo, é criado um perfil do usuário no qual estão contidas as preferências do usuário. Este perfil do usuário é, então, comparado aos documentos que chegam ao sistema e são classificados como de interesse para aquele usuário ou são simplesmente descartados. Por exemplo, esta abordagem pode ser adotada para selecionar, de acordo com o perfil do usuário, notícias dentre milhares que são apresentadas todos os dias.

Neste trabalho será utilizando o tipo de consulta ad hoc, pois o mecanismo de IR desenvolvido como objetivo deste trabalho funciona

22

integrado à uma base de dados na qual o número de inclusões ou remoções de documentos é muito baixo.

3.3. Modelos de Recuperação de Informação

Os primeiros sistemas de IR eram sistemas booleanos os quais permitiam aos seus usuários especificar suas consultas através de uma combinação de operadores booleanos AND, OR e NOT. Embora este tipo de mecanismo retorne o resultado em uma ordem, ele não considera a noção de relevância e, portanto, não realiza uma classificação dos objetos retornados de acordo com a sua relevância em relação à consulta.

A maioria dos mecanismos de IR atuais aplica algum tipo de ranking sobre os seus resultados, isto é, o sistema classifica os objetos retornados de acordo com a sua relevância considerando a consulta realizada pelo usuário. Esta tarefa é realizada através da atribuição de um score para cada um dos objetos e de acordo com este score é realizada a classificação.

Esta seção apresenta os três modelos clássicos de IR chamados Booleano, Vetorial e Probabilístico. O modelo vetorial é apresentado em maiores detalhes por ter sido escolhido para uso neste trabalho.

3.3.1. Caracterização Formal de um Modelo de IR

Definição: Um modelo de IR é uma quádrupla [D, Q, F, R(qi, dj)] onde:

(1) D é o conjunto composto pelas representações dos objetos da coleção;

(2) Q é o conjunto composto pela representação da consulta do usuário;

(3) F é o framework para modelar as representações dos documentos, da consulta e das duas relações;

(4) R(qi, dj) é uma função de ranking que associa um score a uma consulta qi є Q e a um documento dj є D.

Para a construção de um modelo, a primeira tarefa é determinar como será feita a representação dos documentos da coleção. A tarefa seguinte é definir um framework no qual estas representações possam ser modeladas. Neste framework também devem estar incluída a capacidade de utilização de uma função de ranking.

3.3.2. Modelo Booleano

O modelo Booleano é o modelo mais simples. Este modelo é baseado na teoria dos conjuntos. As consultas submetidas para esse modelo são expressões Booleanas as quais possuem uma semântica bem definida. Devido à simplicidade inerente deste modelo, ele recebeu grande atenção nos últimos anos.

O modelo Booleano sofre de algumas desvantagens. A sua estratégia de recuperação é baseada em um sistema binário, ou seja, ou um documento é considerado relevante ou é considerado não relevante. Desta forma, o modelo Booleano acaba parecendo mais um com um sistema de recuperação de dados. Outra desvantagem deste modelo é o fato de que suas consultas são

23

especificadas através de expressões Booleanas. Apesar de uma expressão Booleana ter uma semântica bem definida, o processo de tradução da necessidade de informação do usuário em uma expressão Booleana pode ser uma tarefa relativamente complicada e acaba na maioria dos casos não correspondendo a real necessidade do usuário.

3.3.3. Modelo Vetorial

Neste modelo são utilizados pesos para os termos presentes no documento e estes pesos são utilizados para computar o grau de similaridade entre os documentos e a consulta submetida.

Uma coleção de documentos contendo n documentos os quais são indexados por m termos pode ser representado como uma matriz m x n. Utilizando o modelo vetorial, pode-se interpretar as colunas da matriz como sendo os vetores dos documentos enquanto as linhas são consideradas os vetores dos termos.

Na Figura 3.1 é apresentado um exemplo de como é feita esta representação através da matriz de termos x documento. Por motivos de simplificação, foram utilizados títulos de artigos como exemplo de documentos.

Termos T1: document T2: improve T3: information T4: proximity T5: modern T6: retrieval T7: search T8: xml

Documentos D1: Searching XML Documents D2: Proximity Search of XML D3: Improving XML Retrieval D4: Modern Information Retrieval

Matriz termos x documentos

wt1 0 0 0 0 0 wt2 0 0 0 0 wt3 A = 0 wt4 0 0 0 0 0 wt5 0 0 wt6 wt6 wt7 wt7 0 0 wt8 wt8 wt8 0

Figura 3.1 – Termos, documentos e a matriz termos x documentos

Um formato genérico para representação do cálculo dos pesos pode ser visto como

aij = lij . gj,

onde lij seria o peso local (considerando apenas o documento) associado ao documento e gi o peso global (considerando a coleção de documentos). Este formato é chamado de tf-idf (do inglês term frequency–inverse document frequency) no qual o tf representa o cálculo do peso local enquanto o idf representa o cálculo do peso global para um determinado termo. A maneira mais utilizada para o cálculo destes dois pesos é mostrada na Figura 3.2. Desta forma, obtém-se que o cálculo do peso de cada termo é alcançado através da multiplicação dos fatores ��,� e ��.

As consultas do usuário também são representadas como um vetor. Considere, por exemplo, que a consulta “search XML” seja submetida ao sistema. O vetor referente à consulta é o seguinte: q = ( wt7 wt8 0 0 0 0 0 0 )T. O processamento de uma consulta pode ser visto como uma procura no espaço

24

de coluna da matriz A. Uma das formas mais simples e mais utilizadas para realizar este processo é utilizando a medida do cosseno do ângulo entre o vetor da consulta e os vetores dos documentos. Considerando aj como o j-ésimo vetor de documento, ou seja, a j-ésima coluna da matriz, então, o cosseno entre o vetor de consulta e os vetores de documentos pode ser calculado através da seguinte equação:

cos � = ∑ �� . ��

�∑ �� . �∑ ��

Após a realização do cálculo para cada um dos documentos da coleção, aqueles documentos que tiveram como resultado um valor acima de um limiar estabelecido no mecanismo de busca, são considerados relevantes de acordo com a consulta submetida.

��,� = ��,�∑ ��,��

Onde n é o número de ocorrências do termo ti no documento dj e o denominador é o número de ocorrências de todos os termos no documento dj.

�� = log |�||{�� : �� ∈ ��}|

Onde D é o número total de documentos e o denominador é o número de documentos nos quais o termo ti está presente.

Figura 3.2 – Exemplo de mecanismo para cálculo do peso

As principais vantagens do modelo vetorial são o uso de pesos para cada termo indexado e a sua capacidade de realizar um match parcial possibilitando uma maior flexibilidade no momento da busca pelos termos presentes na consulta. Neste sentido, outro ponto de destaque deste modelo é a capacidade de ranquear os resultados de acordo com o valor calculado para a distância entre os vetores de documento e o vetor de consulta. Além de todas estas vantagens, o modelo vetorial ainda é um modelo simples o que faz dele um dos modelos mais populares em IR.

Uma grande vantagem do modelo vetorial em relação ao modelo Booleano é a capacidade de atribuir peso aos termos. A atribuição de peso aos termos é uma abordagem muito utilizada e tem como principal objetivo melhorar o desempenho do mecanismo de IR. Desempenho, neste caso, se refere às medidas de revocação e precisão (seção 3.5).

3.3.4. Modelo Probabilístico

O modelo probabilístico, também conhecido como binary independence retrieval (BIR), tem como idéia fundamental a existência de um e apenas um conjunto de documentos que contém toda a informação relevante para uma determinada consulta. Este conjunto é comumente chamado de conjunto ideal.

Este modelo assume que o processo de especificação de uma consulta é o processo de especificação das propriedades do conjunto ideal. O problema é que não se sabe exatamente quais são as características que definem este conjunto. Desta forma, a partir da consulta é gerada uma descrição probabilística inicial do conjunto ideal e esta descrição é, então, utilizada para

25

retornar o primeiro conjunto de documentos. A partir deste ponto, um processo de interação com o usuário é iniciado com o objetivo de melhorar a descrição probabilística que define o conjunto de ideal. Este processo de refinamento da descrição pode ser visto da seguinte forma: o usuário analisa o resultado retornado e classifica quais documentos são relevantes. O mecanismo de IR usa esta informação para refinar a descrição e gerar um novo conjunto de resultados. Através da repetição deste processo, espera-se chegar à descrição probabilística que define o conjunto ideal.

O modelo probabilístico supõe que para uma dada consulta q e um documento d, é estimada a probabilidade de o usuário classificar o documento como sendo relevante. Esta probabilidade depende apenas da representação da consulta e do documento. O modelo ainda considera a existência de um conjunto ideal o que significa que os documentos presentes nesse conjunto são considerados relevantes, enquanto os que não fazem parte dele são considerados não relevantes. Esta suposição causa alguns problemas devido ao fato de não explicitar como o cálculo da probabilidade deve ser feito.

Desta forma, uma maneira sugerida para definir este modelo seria: uma consulta q é um subconjunto dos termos indexados. O conjunto R é o conjunto de documentos relevantes enquanto que S é o conjunto de documentos não relevantes. Assumindo que P(R|dj) seja a probabilidade do documento dj ser relevante e P(S|dj) a probabilidade do mesmo documento não ser relevante, a medida de similaridade entre o documento dj e a consulta q pode ser definida como a razão.

A vantagem do modelo probabilístico é a capacidade de classificar os resultados de acordo com a probabilidade de serem relevantes. Porém, existem algumas desvantagens, como, por exemplo, o fato deste modelo não considerar a freqüência com que os termos aparecem no documento e também a necessidade em definir a separação inicial dos documentos em relevantes e não relevantes.

3.3.5. Considerações sobre os modelos de IR

De uma maneira geral, o modelo Booleano é considerado o mais fraco entre estes modelos por não ter a capacidade de lidar com match parcial. Existe ainda uma controvérsia se o modelo probabilístico seria melhor que o modelo vetorial, porém, esta opinião é refutada por diversos pesquisadores e pela comunidade Web, o que faz com que o modelo vetorial ainda seja o mais utilizado.

3.4. O Processo de Recuperação de Informação

Nesta seção será apresentada a visão do autor sobre o processo de recuperação de informação e ao final da seção, o autor sugere uma arquitetura de mecanismo para a tarefa de IR. Esta arquitetura proposta tem como objetivo explicitar os componentes e os processos relacionados aos mecanismos de IR.

A Figura 3.4 ilustra o processo de IR. Inicialmente, antes mesmo que o processo de procura possa ser iniciado, a tarefa de um mecanismo de IR é gerar uma estrutura de índices. A tarefa de geração dos índices é chamada

26

Indexação do Texto. Este processo consiste no percorrimento dos documentos da coleção, criando uma visão lógica destes documentos e finalmente gerando a estrutura de índices nas quais dados dos documentos serão armazenados. A tarefa de determinar quais documentos serão indexados é normalmente atribuída ao encarregado do conjunto de dados. Após a definição dos documentos a serem indexados, o mecanismo de IR está pronto para construir a estrutura de índices sobre a qual o processo de busca será efetuado. Durante o processo de criação dos índices, alguns subprocessos são aplicados sobre o texto. Estes subprocessos serão especificados mais adiante neste trabalho.

A partir do momento que temos os documentos indexados, o processo de recuperação pode ser iniciado. Primeiramente o usuário define uma consulta, através da linguagem de consulta provida pelo sistema, e a submete ao mecanismo de IR. A consulta é submetida às mesmas operações realizadas sobre os documentos indexados. A seguir, a consulta é avaliada pelo mecanismo de busca que recupera os documentos relevantes considerando a consulta submetida. Antes que estes objetos serão exibidos ao usuário, eles passam pelo processo de ranking. O processo de ranking será responsável pela classificação dos documentos de acordo com a sua relevância. Após termos os objetos ordenados, eles serão exibidos ao usuário como resultado.

Figura 3.3 – Mecanismo de recuperação de informação

Tarefa do Usuário

Visão Lógica dos Documentos

Análise do Texto

Conjunto de Termos

Banco de Dados XTC

Coleção de Documentos

Consulta do Usuário

Índices Consulta

Busca

Objetos Retornados

Ranking

Objetos Ordenados

Indexação Processamento

da consulta

27

3.5. Avaliação de Mecanismos de IR

A avaliação de um mecanismo de IR é determinada pela opinião do usuário, ou seja, se ele esta satisfeito com o conjunto de resposta, o que significa que ele encontrou a informação que procurava. Para um mecanismo de recuperação de informação, existem duas medidas específicas que devem ser utilizadas para avaliar o seu desempenho. Estas medidas são conhecidas como revocação e precisão [14].

• Precisão: é a razão entre o número de objetos relevantes que foram retornados pelo número total de objetos retornados.

!"#$�%ã& = �'�(

• Revocação é a razão entre o número de objetos relevantes que foram retornados pelo número de objetos relevantes que estão presentes na coleção.

"#)&$�çã& = �'*'

Como os mecanismos de IR normalmente retornam os documento em ordem decrescente de similaridade com a consulta, e os usuários tendem a verificar os documentos na ordem de apresentação, é necessário considerar esta ordem na avaliação do mecanismo. Uma das medidas que considera a ordem de apresentação dos documentos é a Mean Average Precision. A MAP é a média das precisões obtidas quando cada documento relevante da coleção é encontrado na lista de documentos recuperados.

Além destas medidas de avaliação, as medidas de tempo (tempo para construção das estruturas de índices e tempo para avaliação de uma consulta) e espaço (espaço utilizado pela estrutura de índices) também podem ser consideradas neste processo de validação do mecanismo.


Neste capítulo introduziu-se o conceito de recuperação de informação e a diferença entre recuperação de informação em relação à recuperação de dados. Realizou-se uma discussão sobre os principais modelos utilizados no desenvolvimento de mecanismos de IR, destacando informações relevantes a cerca do seu funcionamento e suas restrições.

Por fim, o autor apresenta a sua visão sobre o processo de recuperação de informação. Na Figura 3.4 é feita uma ilustração da visão do autor sobre a tarefa de IR e são apresentados os subprocessos envolvidos nesta tarefa. Finalmente, são citadas as principais medidas de avaliação para mecanismos de IR.

28

4. Preparação do Documento

Neste capítulo é apresentado o processo de criação do índice para cada documento e as operações que são aplicadas no conteúdo destes documentos. Também são discutidos alguns mecanismos de indexação que são utilizados para acelerar o processo de busca e finalmente são abordadas questões a respeito das estruturas de dados utilizadas para armazenar o índice.

Um mecanismo de IR executa uma busca sobre uma coleção de documentos com o objetivo de retornar informação relevante para o usuário. Para evitar que o sistema tenha que percorrer toda a coleção toda vez que uma consulta é submetida, mecanismos de IR necessitam de uma estrutura que indexa o conteúdo dos documentos. Desta forma, antes mesmo que o processo de recuperação possa ser iniciado, é necessário gerar as estruturas de índice para os documentos nos quais se deseja executar as operações de busca.

4.1. Indexação do Documento

Nem todos os termos de um documento são igualmente significantes para representar a sua semântica. Os modelos de IR assumem que cada documento pode ser descrito por um conjunto de termos e que estes termos ajudam a descrever o conteúdo do documento em questão. Outra alternativa é representar um documento pelo seu conjunto total de palavras. Aplicando esta técnica, podemos dizer que o mecanismo de IR adota uma visão lógica do texto completo.

Figura 4.1 – Descrição do processo de indexação

Entretanto, nem todas as palavras do texto são igualmente relevantes para representar a semântica do documento. Em outras palavras, pode-se dizer que algumas palavras possuem mais significado que outras. Utilizar todo

Banco de Dados XTC

Coleção de Documentos

Índices Indexação

Documento Análise do Texto

Visão do Documento

29

o conjunto de palavras de um documento para a criação de seu respectivo índice pode gerar ruído durante a tarefa de recuperação. Por exemplo, um termo como “the” não possui significado e pode levar o mecanismo de recuperação a retornar diversos resultados não relacionados à consulta realizada.

A Figura 4.1 ilustra o processo de indexação. O processo de criação dos índices começa com a seleção dos documentos que devem ser indexados. Esta tarefa é normalmente realizada pelo administrador do banco de dados ou pelo responsável pelos dados para os quais se deseja criar os índices. Depois desta seleção, para cada um dos documentos selecionados, algumas operações sobre o texto devem ser realizadas. Estas operações, baseadas no documento original, geram uma visão modificada para aquele documento, chamada de visão lógica do documento. Esta visão lógica contém apenas os termos que serão utilizados na criação do índice. Uma vez que esta visão lógica é definida, o processo de indexação é executado criando a estrutura do índice para o documento em questão. Finalmente esta estrutura é então armazenada e será posteriormente utilizada pela ferramenta de busca.

4.2. Análise do Texto

O processo de análise do texto executa algumas operações sobre o texto analisado antes que ele comece a ser indexado. Esta análise percorre todo o documento aplicando operações como análise léxica, remoção de stopwords entre outras, e coletando os termos que representam a informação contida no documento.

Este processamento pode ser dividido em três etapas:

• Análise léxica do texto com o objetivo de tratar dígitos, pontuação e o tratamento de letras maiúsculas e minúsculas.

• Eliminação de stopwords com o objetivo de filtrar as palavras eliminando as que serão menos significantes para o processo de recuperação.

• Aplicação da técnica conhecida como stemming com o objetivo de remover prefixos e sufixos diminuindo assim a ocorrência de várias palavras que possuem o mesmo stem.

4.2.1. Análise Léxica

Análise léxica é o processo de converter uma seqüência de caracteres (texto do documento) em uma seqüência de palavras (as palavras candidatas a serem utilizadas no índice). Embora, a primeira vista, a tarefa de identificar os termos do texto pareça simples, bastando-se para isso identificar os espaços como separadores, existem mais tarefas que estão associadas à tarefa de análise do que apenas realizar a checagem de separadores.

Dígitos normalmente não são bons termos para serem indexados. Por exemplo, considere um usuário interessado em artigos publicados no ano de 2006 e que tratem sobre recuperação de informação. Tal consulta poderia ser especificada através dos seguintes termos {recuperação, informação, artigo, 2006}. A presença do termo “2006” poderia levar o mecanismo de IR a

30

recuperar uma grande quantidade de documentos que apenas se referem a este ano sem ter nenhuma relação com artigos sobre recuperação de informação. Isto significa que, o sistema irá recuperar vários objetos que são irrelevantes para a consulta submetida.

Por outro lado, seqüências de números podem identificar o código de uma conta bancária, uma identificação pessoal ou ainda um número de cartão de crédito. Todas estas informações podem ser relevantes em um determinado contexto.

A análise léxica também trata com a tarefa de remoção da pontuação. Normalmente todas as marcações de pontuação são removidas. Esta remoção pode ser feita, pois o risco de causar alguma confusão entre os termos do texto é mínimo. Na verdade, existem poucas situações em que a remoção da pontuação poderia gerar problemas. Por exemplo, no caso de o texto conter um trecho de código onde foram definidas duas variáveis, “a.id” e “aid”, a remoção da pontuação, neste caso, faria com que as duas variáveis fossem interpretadas como a sendo o mesmo termo.

4.2.2. Eliminação de Stopwords

Stopwords são termos que aparecem tão freqüentemente em textos que acabam perdendo a sua utilidade como termos de procura, isto é, podem ser considerados inúteis do ponto de vista de recuperação de informação. A eliminação de stopwords é o nome dado ao processo de remoção destes termos. Este processo percorre todo o documento verificando quais palavras constam ou não na lista de stopwords utilizada pelo mecanismo. Caso a palavra conste na lista, ela é descartada e não será utilizada no processo de indexação do documento.

Este problema pode ser solucionado através da eliminação de stopwords. Através desse processo o número de termos que devem ser indexados é reduzido, ou seja, a complexidade para a representação do documento é reduzida.

Apesar de todos esses benefícios, o processo de eliminação de stopwords pode gerar casos nos quais se torna impossível reconhecer frases especificadas na consulta. Por exemplo, a frase “to be or not to be”, dependendo da lista de stopwords utilizada, a frase inteira seria eliminada, forçando o mecanismo de IR a percorrer o documento original para procurá-la.

4.2.3. Stemming

Freqüentemente, o usuário especifica uma palavra em uma consulta, porém apenas uma variante da palavra consta em um documento relevante. Plural, gerúndio, declinações são apenas alguns exemplos de variações sintáticas que podem fazer com que um casamento perfeito entre o termo da consulta e o termo encontrado no documento não seja possível. Este problema pode ser parcialmente solucionado com a substituição das palavras pelos seus respectivos stems. Um stem é a porção da palavra que resta após a remoção de seus sufixos e/ou prefixos.

Stemming [15] possui tradição quando se fala em construção de índices a partir de textos em linguagem natural. Este processo pode ser muito útil para

31

melhorar o desempenho do mecanismo de IR levando em conta que ele reduz o número de variantes de uma palavra para o mesmo conceito. Além disso, stemming ainda reduz o tamanho da estrutura de índice, pois o número de termos diferentes que serão indexados será reduzido.

4.3. Técnicas de Indexação

Existem três técnicas principais de indexação: árvore de sufixos, arquivo de assinatura e arquivo invertido. Esta seção apresenta essas técnicas, sendo que o arquivo invertido é atualmente a técnica mais apropriada para a maioria das aplicações.

4.3.1. Árvore de Sufixos (Suffix Tree)

Árvore de sufixo [14] é uma estrutura de dados em árvore construída contendo os sufixos do texto. Cada posição é considerada como um sufixo e cada sufixo é, então, identificado pela sua posição. Nem todas as posições são indexadas, sendo assim, devem ser definidas quais as posições que serão recuperáveis. Uma variação da árvore de sufixos é o array de sufixos. Um array de sufixos é simplesmente um array contendo todos os ponteiros para os sufixos indexados em ordem lexigráfica. A Figura 4.2 apresenta a árvore de sufixos e o array de sufixos para um texto tomado como exemplo.

00This 05is 08a 10text. 16A 18text 23has 27many 32words. 39Words 45are 49made 54from 59letters.

(a)

59 49 27 18 10 39 32

(b)

Figura 4.2 – (a) Árvore de sufixos para o texto de exemplo (b) Array de sufixos para o texto de exemplo

Padrões como palavras e frases podem ser buscados em um tempo satisfatório neste tipo de estrutura através de uma procura na árvore. Além disso, uma frase pode ser buscada como se fosse uma busca por um termo único. Entretanto, esta estrutura não é apropriada para grandes textos devido à necessidade de espaço que ela utiliza.

4.3.2. Arquivo de Assinatura (Signature File)

Arquivo de assinatura [1,16] é uma estrutura baseada em hash. Esta estrutura utiliza uma função de hash, também chamada de função de assinatura, para mapear as palavras do texto para vetores de bits. Esta técnica divide o texto em blocos de n palavras e atribui um vetor de bits para cada um dos blocos.

1

3

5

6

59 49

27

18

10

39

32

‘l’

‘m’

‘t’

‘w’

‘d’

‘n’

‘ ’

‘.’

‘ ’

‘.’

32

Este vetor é obtido através de uma operação entre os bits de cada uma das palavras que estão contidas naquele bloco. A Figura 4.3 apresenta um texto dividido em blocos e, para cada bloco, o seu respectivo vetor de bits.

Block 1 Block 2 Block 3 Block 4

This is a text. A text has many words. Words are made from letters.

000101 110101 100100 101101

Função de assinatura: H(text) = 000101 H(many) = 110000 H(words) = 100100

H(made) = 001100 H(letters) = 100001

Figura 4.3 – Texto de exemplo com os blocos e o vetor de bits associado à cada um deles

A procura por um termo consiste na tarefa de aplicar a função de hash no termo e, então, comparar o resultado da função com cada um dos blocos. Sendo assim, o percorrimento de todos os blocos é necessário para verificar se a palavra consta no bloco ou não. Neste esquema não é possível realizar a busca por nenhum outro padrão além da busca por um termo simples.

4.3.3. Arquivo Invertido (Inverted File)

Arquivo invertido [1,16], ou lista invertida, é um mecanismo de indexação orientado à palavra. Esta estrutura armazena um mapeamento dos termos para suas localizações em um documento ou em uma coleção de documentos. A estrutura de um arquivo invertido é composta por dois elementos: o vocabulário e as ocorrências. O vocabulário é a lista de palavras que constam no texto. Para cada uma destas palavras, é armazenada uma lista contendo as posições onde estes termos ocorrem. O conjunto de todas estas listas é denominado de ocorrências. A Figura 4.4 apresenta um texto e a sua respectiva lista invertida.

00This 05is 08a 10text. 16A 18text 23has 27many 32words. 39Words 45are 49made 54from 59letters.

Vocabulário Ocorrências

letters made many text

words

59 49 27

10, 18 32, 39

Figura 4.4 – Texto exemplo e a lista invertida para o texto

A procura em um arquivo invertido sempre começa pelo vocabulário. Busca por uma simples palavra pode ser acelerada utilizando uma estrutura de dados adequada, como, por exemplo, uma tabela hash ou uma B-Tree9. Procura por mais de um termo (busca por frase) deve ser separada e cada termo buscado separadamente, gerando uma lista com os resultados para

9 http://en.wikipedia.org/wiki/B-tree

33

cada um deles. Por fim, estas listas devem ser percorridas com a finalidade de encontrar posições de ocorrência comuns entre estes termos.

4.4. Estruturas de índice para documentos XML

Diversas estruturas de índices têm sido propostas para documentos XML. XISS (XML indexing and storage system) [17] é um sistema para indexar e armazenar dados no formato XML. Este sistema é baseado em três estruturas principais chamadas índice de elemento, índice de atributo e índice de estrutura. Além destes índices ainda temos mais dois componentes chamados índice de nomes e tabela de valores. Os três índices principais são utilizados para buscas e percorrimento na estrutura do documento enquanto o índice de nomes armazena todos os nomes de elementos e a tabela de valores é encarregada do armazenamento dos strings (valores dos atributos e texto) contidos no documento.

Figura 4.5 – Representação em árvore de um documento XML

Embora estes índices resolvam eficientemente consultas pela estrutura do arquivo, eles não são adequados para resolver consultas feitas pelo conteúdo dos dados armazenados. Uma estrutura de índices que parece ser mais apropriada para tratar tanto consultas por conteúdo como consultas por estrutura é o XICS (XML Indices for content and structural search) [12]. Esta estrutura é composta por duas estruturas principais, COB-Tree (Content B+-Tree) e STB-Tree (Structure B+-Tree). Os nodos do índice COB-Tree são pares compostos por sufixos do texto e o seu PSP (path sibling pair). Contudo, como já foi apresentado anteriormente, a opção por armazenar sufixos é custosa. Para resolver este problema, a solução adotada foi uma espécie de diferença entre os elementos de texto dos índices. Desta forma, ao invés de armazenar todo o sufixo, são armazenados apenas os termos capazes de identificar unicamente o sufixo dos demais. Enquanto o índice COB indexa o conteúdo do documento, o índice STB armazena a informação referente à estrutura do documento. Ele armazena os PSPs do documento. O PSP é composto por duas informações: identificador do path e o Dewey order associado a ele.

document

section title section

section section section lang

en XML index

We can get texts in the XML document

Nodes in the XML are labeled

Tree index

XML index

(1;1.)

(6;1.1.1.) (5;1.1.1.)

(4;1.1.) (2;1.1.)

(3;1.1.1.)

(4;1.2.)

(6;1.1.2.)

34

A seguir, a Figura 4.6 mostra um exemplo de índice segundo o esquema XICS para o documento apresentado na Figura 4.5.

(a)

(b)

Figura 4.6 – (a) Índice STB-Tree para o documento de exemplo (b) representação parcial do índice COB-Tree para o documento de exemplo


Este capítulo descreveu o processo de indexação de documentos XML. Foram discutidos aspectos importantes sobre esta tarefa e sobre as estruturas de dados envolvidas neste processo. Inicialmente apresentou-se o conceito de indexação de documentos e através da Figura 4.1, o autor expôs a sua visão do processo. Em seguida realizou-se uma discussão sobre as subtarefas que são aplicadas sobre o texto antes mesmo que este possa ser de fato indexado. Por fim, foram apresentadas as estruturas mais comuns para o armazenamento de índices. Primeiramente são discutidas estruturas para organização do índice. Estas estruturas têm como objetivo facilitar a tarefa de pesquisa sobre os dados indexados. Finalmente foram introduzidas duas estruturas de dados para o armazenamento do índice. Neste sentido, foi destacada a estrutura COB-Tree por esta ter sido utilizada como base para o desenvolvimento da estrutura de índice deste trabalho.

1;1.

4;1.1.

4;1.2.

3;1.1.1.

6;1.1.2.

2;1.1.

5;1.1.1.

6;1.1.1.

index, 5;1.1.1

get,6;1.1.1.

texts,6;1.1.2.

We,6;1.1.2.

are,6;1.1.1. can,6;1.1.2.

document,6;1.1.2.

en,3;1.1.1.

get,6;1.1.2. in the XML,6;1.1.1.

in the XML,6;1.1.2.

index,2;1.1.

6;1.1.1.

35

5. Recuperação de Informação integrada ao Banco de Dados XTC

Neste capítulo será apresentado o mecanismo de recuperação de informação desenvolvido de maneira integrada ao projeto XTC. Neste sentido, será discutido o modelo de IR utilizado e as características de todos os subprocessos envolvidos na tarefa de recuperação de informação. Da mesma forma, serão detalhadas as estruturas envolvidas e a sua relação com o processo de IR. Ao final do capítulo são apresentados os resultados experimentais com a finalidade de validar a abordagem proposta.

5.1. Modelo de Recuperação de Informação

Observando a estrutura de um documento XML podem-se notar dois aspectos importantes em relação à organização dos dados nele contidos: a estrutura hierárquica de seus elementos e a presença de marcações que descrevem o seu conteúdo. Estas duas características são relevantes para recuperação de informação, pois é através delas que a recuperação de unidades (elementos) do documento é possível.

Neste contexto, um importante ponto a ser destacado é a introdução de uma nova unidade de recuperação. No modelo proposto, as unidades retornadas não são documentos completos, mas sim fragmentos do documento que durante o processo de busca foram classificados como relevantes em relação à consulta submetida pelo usuário.

Este trabalho propõe a utilização de um modelo vetorial de recuperação de informação, no qual as unidades recuperáveis são elementos do documento XML que possuem informação de texto associada. No modelo utilizado, considera-se que o texto é representado por um vetor de termos. Como a definição de termo não é inerente ao modelo, optou-se por defini-lo como uma palavra do texto. Desta forma, como as palavras do texto são utilizadas como termos, cada palavra passa a ser considerada como uma dimensão do espaço vetorial. Sendo assim, se a palavra pertence ao texto, ela recebe um valor diferente de zero para a dimensão referente àquela palavra. Definiu-se como método para cálculo deste valor a medida tf-idf. Considerando que um texto possui apenas um conjunto de palavras enquanto o vocabulário contém todas as palavras da coleção, a maioria dos vetores que representam um objeto são vetores esparsos10. Outro detalhe a ser destacado é o fato de operar-se

10

Vetor que possui poucos valores diferentes de zero.

36

sempre no quadrante positivo do espaço vetorial, sendo assim nenhum vetor recebe um valor negativo.

Para a tarefa de atribuição de um valor numérico a um objeto, o modelo utiliza a similaridade entre o vetor da consulta e o documento do vetor. A similaridade entre dois vetores, mais uma vez, não é inerente ao modelo vetorial. Desta forma, optou-se por utilizar como medida de similaridade a distância entre os vetores. Para isso foi adotada a medida do cosseno do ângulo entre os vetores. Esta medida é calculada através da seguinte fórmula:

%�+,�� , �- = ./0 . 10

2./02 . 3 103

= ∑ 4�,� . 4�,1(��∑ 4�,��(�� . �∑ 4�,1�(��

Esta decisão baseia-se na propriedade de que está medida varia entre o valor 1.0 para vetores idênticos e 0.0 para vetores ortogonais. Uma alternativa para simplificação dos cálculos é a utilização do produto interno entre os vetores. Se os vetores que estão sendo comparados são vetores unitários, a cálculo do cosseno passa a ser igual ao cálculo do produto interno entre eles dado pela seguinte fórmula:

%�+,�� , �- = ./0 . 10= 5 4�,�

(��

. 4�,1

5.2. Índice

Em um mecanismo de IR baseado na utilização de índices, antes mesmo que o processo de recuperação possa ser iniciado, é necessária que a tarefa de criação dos índices seja executada. Esta tarefa é usualmente alocada ao administrador da base de dados ou ao responsável pelos dados para os quais se deseja criar a estrutura de índices.

Com base na estrutura do índice COB-Tree proposto em [12], utilizou-se uma estrutura semelhante de índice baseada em uma lista invertida armazenada em uma B-Tree, onde cada nodo da árvore armazena um registro. Um registro é uma estrutura composta por um termo (palavra do documento) seguido da freqüência global do termo e finalmente uma lista de ocorrências do termo. Cada ocorrência é composta pelo identificador do documento e pela freqüência associada ao termo no documento em questão. A seguir, são detalhadas as estruturas citadas.

5.2.1. Registro

O registro é a unidade básica que contém um termo, o valor de freqüência global para o termo referido e uma lista de ocorrências para aquele termo. Retirando-se as palavras que constam na lista de stop-words (palavras que são ignoradas durante o processo de indexação), para cada palavra diferente do texto será gerado um registro. O registro é constituído por três campos: o termo, a sua freqüência global e a lista de ocorrências.

• Termo: como as palavras de um texto têm um tamanho variável, optou-se por definir um tamanho máximo como sendo de 128 bytes. A palavra armazenada não deve exceder este tamanho:

37

caso contrário, o termo será truncado e apenas os seus primeiros 128 bytes serão armazenados. Esta restrição em relação ao tamanho máximo de um termo a ser indexado é feita devido à utilização de métodos internos do gerenciador de banco de dados XTC. Este tamanho máximo do termo a ser indexado pode ser alterado através da modificação dos arquivos de configuração do XTC. Porém, como este trabalho propõe-se a ser totalmente integrado com o banco de dados XTC, adotou-se esta configuração padrão.

• Freqüência global: este campo é responsável pelo armazenamento do valor de freqüência global do termo (idf). Este valor de freqüência é atualizado à medida que novos documentos são incluídos no índice.

• Lista de ocorrências: uma ocorrência é responsável pelo armazenamento da informação de localização e freqüência (tf) do termo para aquela ocorrência. Desta forma, a ocorrência é um campo subdivido em dois subcampos: localização e freqüência. No subcampo localização é armazenado o deweyID do elemento onde a palavra ocorre. O deweyID fornece informação a cerca da estrutura do documento, isto é, identifica o caminho completo desde o nodo raiz até o nodo folha no qual o termo aparece. Além disso, o deweyID identifica unicamente cada um dos nodos do documento XML tornando possível a recuperação de fragmentos do documento. Ao mesmo tempo em que é necessário o armazenamento de informação sobre a localização do termo, também se optou pelo armazenamento da informação de freqüência associada aquele termo para cada elemento onde ele ocorre. A informação de freqüência é utilizada no cálculo de relevância do documento em relação à consulta realizada pelo usuário.

5.2.2. Construção do Índice

A construção de um índice não é apenas compreendida pela tarefa de extração de palavras do texto e construção de uma estrutura de dados contendo estes termos.

A primeira tarefa a ser executada é a análise léxica do texto a ser indexado. A análise léxica visa tratar questões referentes ao tratamento de dígitos, pontuações e o case das letras do texto. Em relação aos dígitos, optou-se por excluí-los da lista de termos a serem indexados tendo em vista que a tarefa de determinação sobre a sua importância como termos do índice ainda está mal resolvida. Quanto aos símbolos de pontuação, apenas o hífen é mantido enquanto todo o restante dos símbolos é removido. Decidiu-se por manter o hífen entre palavras pois este símbolo de pontuação ocorre relativamente poucas vezes fazendo com que o termo que o utiliza seja importante para a identificação do documento.

O próximo passo compreende a aplicação de uma lista de stopwords. Esta tarefa esta relacionada com a remoção de palavras que tem pouco ou

38

nenhum valor como palavra a ser indexada. Do ponto de vista de compressão de dados, a remoção de stopwords elimina a necessidade de tratar palavras desnecessárias reduzindo o tamanho do índice e a quantidade de tempo e espaço necessário para construir a estrutura.

Finalmente a última tarefa antes da indexação do texto é o processo de stemming. Stemming faz a remoção de sufixos com a finalidade de reduzir a palavra ao seu stem. Apesar da aparente vantagem na aplicação desta técnica, em alguns casos ela pode levar o mecanismo de busca a retornar documentos que não são relevantes. Por exemplo, uma consulta pelo termo reformation levaria o mecanismo a considerar relevantes termos como reformatory, reformative e reformism. O stemmer utilizado neste trabalho é de domínio público e conhecido como Porter Stemmer11. Este stemmer adota uma abordagem baseada em seqüências de vogais e consoantes diferente de outras abordagens que seguem o princípio de procurar o stem que melhor representa a palavra em um dicionário de stems.

Após a aplicação das tarefas citadas, obtém-se a visão lógica do documento na qual apenas os termos a serem indexados estão presentes. Desta forma, para cada termo diferente contido na visão lógica do documento será criada uma estrutura do tipo Registro. Após a criação do registro, ocorre a sua inserção na lista invertida. Um detalhe importante referente à utilização de listas invertidas é o fato de que este tipo de estrutura não armazena duplicatas. Neste sentido, caso um registro para o referido termo já conste na lista, o registro é então atualizado com o dado a cerca da nova ocorrência enquanto que o registro recém gerado pelo processo de indexação é descartado.

Por fim, a tarefa final do processo de criação do índice é o armazenamento da lista invertida em uma B-Tree. Optou-se por este tipo de estrutura de dados, pois ela garante tempo de execução logarítmico para as operações de busca, inserção e deleção. Além disso, o gerenciador de banco de dados XTC já possui uma implementação deste tipo de estrutura. Informações sobre a implementação do processo de podem ser encontradas no Anexo 1.

5.3. Consulta

Uma consulta é a formulação da necessidade de informação de um usuário. De uma maneira geral, quando se trabalha com a tecnologia XML, podem-se separar as consultas em dois tipos: consultas por conteúdo (content-only) ou consultas por estrutura e conteúdo (content-and-structure).

A seguir, são apresentadas estas duas formas de consulta bem como apresentados exemplos de cada uma delas.

• Consulta por conteúdo (CO):

Os documentos XML são essencialmente longas seqüências de palavras e sob esta perspectiva, a consulta mais elementar que pode ser formulada a um mecanismo de IR é uma palavra.

11

http://tartarus.org/martin/PorterStemmer/

39

O conceito de palavra ou termo pode ser facilmente definido como uma seqüência de caracteres de um alfabeto. Neste sentido, uma consulta por conteúdo consiste em definir um conjunto de palavras que expressam a necessidade de informação do usuário. O resultado da consulta é um conjunto de documentos contendo pelo menos uma das palavras especificadas

• Consulta por conteúdo e estrutura (CAS):

Além de considerar que uma coleção de documentos XML pode apenas ser consultada apenas pelo seu conteúdo, é interessante levar em conta a possibilidade de efetuar consultas utilizando também construtos estruturais. Através da combinação de dados do conteúdo e da estrutura, é possível alcançar uma melhora na qualidade dos objetos retornados em um sistema de IR.

Inicialmente, é efetuada a consulta pelos termos do conteúdo dos documentos. Em seguida, no conjunto de objetos retornados, são efetuadas verificações em relação à estrutura de cada documento de acordo com a informação estrutural definida pelo usuário na consulta. O resultado é um conjunto de documentos que, além de conter pelo menos um das palavras especificadas, esta de acordo com o construto estrutural definido na consulta.

5.3.1. Linguagem de Consulta

Linguagens de consulta são linguagens especializadas para requisição de informação, na maioria dos casos, em bancos de dados. Como parte deste trabalho, foi desenvolvida uma linguagem de consulta baseada em XPath [6] e denominada MicroXPath. O foco principal da linguagem foi gerar uma linguagem intuitiva. Para isso, utilizando a ferramenta ANTLR [10] e baseado na gramática da linguagem XPath disponível para esta ferramenta, foram feitas restrições na utilização de seus recursos, gerando assim uma linguagem de fácil utilização e entendimento.

Nesta seção será apresentada a linguagem de consulta utilizada neste trabalho. Esta tarefa será realizada através da apresentação da gramática desenvolvida com o auxílio da ferramenta ANTLR. Em seguida, será feita uma descrição sobre a tarefa de integração da linguagem de consulta com o interpretador de comandos do gerenciador de banco de dados XTC.

5.3.1.1. MicroXPath

A Tabela 5.1 a seguir apresenta as regras da gramática e uma breve explicação a respeito de cada uma delas.

microXPath : pathExpr | predicate ;

A linguagem MicroXPath possibilita ao usuário a construção de consultas CO e CAS. Consultas CAS podem ser feitas através da utilização da regra pathExpr enquanto consultas CO utilizam a regra predicate.

pathExpr : ('/' absolutePathExpr) | ('//' relativePathExpr) ;

Esta regra tem como objetivo permitir ao usuário a inclusão de construtos estruturais na consulta. Para isso, a linguagem possibilita o uso de dois tipos de construtos estruturais. Ambos são definidos nas regras seguintes.

40

absolutePathExpr : primaryStep = stepExpr

A regra absolutePathExpr define um caminho absoluto. Esta é a maneira mais estrita de se

(('/') trailingStep = stepExpr )* predicate ;

definir um construto estrutural e, portanto, o seu uso esta associado a um bom conhecimento sobre a estrutura do documento. Esta regra define o caminho completo deste o nodo raiz até o nodo folha o qual deve conter um dos termos da consulta.

relativePathExpr : tagName predicate ;

A regra relativePathExpr fornece uma maneira mais flexível de se definir um construto estrutural. Ao mesmo tempo que algum conhecimento sobre a estrutura do documento é necessário, esta regra permite ao usuário definir apenas o nodo folha o qual deve conter um dos termos da consulta.

tagName : PathName ;

Este regra define o passo final onde o nome da tag é associado a um token PathName. Esta regra é necessária para o correto funcionamento do mecanismo de processamento da consulta.

predicate : '[' predicateExpr ']' ;

Predicate é a regra que define o início do conjunto de termos que será utilizado no processo de busca.

predicateExpr : primaryContent = expr content = (',' expr)* ;

Esta regra possibilita ao usuário definir um número arbitrário de termos a serem buscados nos documentos da coleção.

expr : ContentItem ;

Esta regra define o passo final onde um termo da consulta é associado a um token ContentItem. Esta regra é necessária para o correto funcionamento do mecanismo de processamento da consulta.

Tabela 5.1 – regras da linguagem de consulta MicroXPath

Com base nas regras definidas pela gramática da linguagem MicroXPath e na representação em árvore de um documento XML (Figura 5.1), a Tabela 5.2 apresenta algumas consultas exemplo e os nodos retornados para cada uma destas consultas.

ID da Consulta Consulta ID Nodos Recuperados

C0 C1 C2 C3

[“Birbeck”] /bib/book/author[“Birbeck”] //author[“Birbeck”] /bib/book/title[“Two”,“Faces”]

[2, 3, 4] [3]

[2, 3] []

Tabela 5.2 – consultas de exemplo e nodos recuperados para cada consulta

41

Figura 5.1 – Representação em árvore de um documento XML

5.4. Processamento da Consulta

O processamento da consulta tem como objetivo a transformação de uma consulta especificada através de uma linguagem de alto nível, como por exemplo, a linguagem desenvolvida neste trabalho, em uma estrutura compreensível e processável pelo mecanismo de busca.

Após a submissão da consulta pelo usuário, ela passa pelo processo chamado parsing. Em Ciência da Computação, parsing ou análise sintática, é o processo que consiste na análise de uma seqüência de tokens com a finalidade de determinar se a sua estrutura esta de acordo com uma determinada gramática. A tarefa de parsing gera tokens para um dado conjunto de caracteres e estes tokens são então processados por um parser. Por sua vez, o parser determina se os tokens referenciam estruturas válidas e se estão na seqüência correta. Por fim, este processo é finalizado com a geração de uma estrutura de dados que será então utilizada pelo mecanismo de busca.

Para a tarefa de criação do parser, foi utilizada a ferramenta de geração de parsers ANTLR. ANTLR é uma ferramenta que provê um framework para a construção de compiladores, reconhecedores, e tradutores a partir da descrição de uma gramática. ANTLR automatiza a construção de reconhecedores de linguagem. Por exemplo, para uma dada gramática, a ferramenta gera um mecanismo que determina se uma sentença (texto de entrada) está de acordo ou não com as especificações feitas na gramática utilizada. Após a validação da entrada, ocorre a geração da estrutura interna de representação da consulta. Por fim, esta estrutura é utilizada pelo mecanismo de busca para o processamento da consulta.

A seguir são apresentados em detalhes os processos de avaliação da consulta, tanto para os construtos estruturais, como para os referentes ao conteúdo do documento.

5.4.1. Estrutura

Para a execução da tarefa de verificação da estrutura dos documentos retornados utilizou-se a técnica de casamento de restrição estrutural descrita em [11].

bib

music

Two Faces

book

title

text author author title

Peter Birbeck

Mark Birbeck

XML document by Birbeck

Professional XML

1

2

3

4

5

42

Uma observação importante que deve ser levada em conta é o fato de que existem muitos casos nos quais conteúdos similares são descritos utilizando diferentes nomes de tags e diferentes estruturas. Um exemplo claro da diferença estrutural entre conteúdos similares esta no fato de que algumas sociedades acadêmicas, como ACM e IEEE-CS, publicam seus dados bibliográficos em formato digital, e alguns deles também fornecem no formato XML. Tal situação dá origem a alguns problemas. Um deles é a diversidade de nomes para tags em dados XML. Por exemplo, informação sobre artigos pode ser descrita utilizando-se a tag “paper” ou pela tag “artigo”. Outro problema é a diferença estrutural entre os dados XML. Por exemplo, para um documento, os autores de um artigo podem ser representados sob um caminho como /papers/paper/autores/autor, enquanto que outro descreve o mesmo tipo de dado sob o caminho /artigos/artigo/autor.

Para tratar os problemas apresentados, neste trabalho foi utilizado um esquema de expansão de consultas por conteúdo através da utilização de uma ontologia12 e o casamento aproximado de caminhos por meio da utilização de similaridade. Estes dois métodos utilizados, para a expansão da consulta e para o casamento de caminhos, são explicados nas seções seguintes.

5.4.1.1. Expansão dos nomes das tags

Para realizar a expansão dos nomes de tags emprega-se o uso de uma ontologia. Como este trabalho não está vinculado a nenhum domínio específico, optou-se pela utilização de um dicionário de propósito geral. O exemplo mais conhecido deste tipo de dicionário para a língua inglesa é o WordNet [9]. Esta ontologia é apropriada para dados XML que contém termos gerais como nomes de tag, não sendo apropriada para documentos que contenham termos de domínios específicos.

O componente básico para a descrição semântica de uma palavra no WordNet é o synset. Synset representa o conjunto de sinônimos para uma determinada palavra. A Figura 5.2 apresenta o resultado da consulta pelo termo author no dicionário WordNet utilizando o software WordNet 2.1 Browser.

O WordNet define 6 tipos de synset: ADJECTIVE, ADJECTIVE_SATELLITE, ADVERB, ALL_TYPES, NOUN e VERB. Como podemos observar na Figura 5.2, para o termo author foram retornados dois tipos de sinônimo: NOUN e VERB. Como na maioria dos casos apenas substantivos são utilizados como nomes de tags, a expansão de nomes ocorre utilizando-se o conjunto NOUN retornado. Considerando ainda o exemplo da Figura 5.2, para o nome de tag author, o conjunto final de termos que serão utilizados na expansão seria {author, writer, generator, source}. Para exemplificar a tarefa de expansão de construto estrutural, a Tabela 5.3 apresenta uma consulta de exemplo, os sinônimos obtidos na consulta à ontologia e por fim o conjunto expandido de caminhos obtidos a partir do caminho original.

12

Vocabulário controlado para domínio específico.

43

Figura 5.2 – Resultado da pesquisa para o termos author no dicionário

WordNet

Consulta: /paper/author

Nomes de tag Sinônimos

paper composition, report, theme, newspaper, newspaper publisher

author writer, generator, source

Caminhos expandidos:

/paper/author /paper/writer

/paper/generator /paper/source

/composition/author /composition/writer

/composition/generator /composition/source

/report/author /report/writer

/report/generator /report/source

/theme/author /theme/writer

/theme/generator /theme/source

/newspaper/author /newspaper/writer

/newspaper/generator /newspaper/source

/newspaper publisher/author /newspaper publisher/writer

/newspaper publisher/generator /newspaper publisher/source

Tabela 5.3 – Exemplo de consulta com o construto estrutura, conjunto de sinônimos retornados e o conjunto de caminhos expandidos

5.4.1.2. Casamento de Caminhos

A distância de edição é uma medida de similaridade entre duas palavras. Ela é definida como o número mínimo de alterações necessárias para transformar uma palavra na outra. Estas alterações podem incluir substituição, inclusão e remoção. Existem algumas variações desta proposta, como por exemplo, a distância de hamming que permite apenas inclusão ou remoção. Neste trabalho adotou-se a distância de Levenshtein13 na qual todas as alterações citadas são consideradas.

13

http://www.merriampark.com/ld.htm

44

Como estas medidas de similaridade são calculadas para um par de strings, quando comparamos um par de expressões de caminho, devemos considerar cada nome de tag como um passo. Suponhamos as seguintes expressões de caminho p1 = /bib/paper/author e p2 = /paper/names/author. A distância de edição pode ser calculada como:

p1 p2

/bib/paper /author /paper/names/author

Custo 1 0 1 0

Para a tarefa de calcular a similaridade (distância de Levenshtein) entre as expressões de caminho, foi utilizada a biblioteca SimMetrics14 que já possui a implementação de diversas medidas de similaridade, entre elas a distância de Levenshtein. Conforme mencionado anteriormente, a similaridade é avaliada para um par de palavras, desta forma, é necessário converter a expressão de caminho em uma palavra processável pela função de similaridade. Para isto, utilizando todo o conjunto de expressões de caminho expandidas, é construído um dicionário onde cada nome de tag é mapeado para um identificador único. A Tabela 5.4 mostra um exemplo de mapeamento para as duas expressões de caminho utilizadas no exemplo logo acima.

Nome de tag Identificador

bib paper names author

A B C D

Tabela 5.4 – Exemplos de mapeamento de nome de tag para identificador

Realizado este mapeamento, as palavras referentes às expressões p1 e p2 que são passadas para a função de similaridade são respectivamente “ABD” e “BCD”.

O resultado da tarefa de verificação da informação estrutural será o maior valor de similaridade comparando-se o caminho do objeto retornado com cada um dos caminhos resultantes da expansão da consulta.

5.4.2. Conteúdo

O casamento de uma consulta no modelo vetorial, considerando apenas os construtos referentes ao conteúdo do documento, é feito através do cálculo da distância entre dois vetores. Neste caso específico, entre o vetor da consulta e o vetor de um documento.

Para a construção destes vetores é realizado o percorrimento da estrutura do índice. Para o vetor da consulta, realiza-se o percorrimento do vocabulário. Durante este percorrimento, é avaliada a similaridade do termo do vocabulário em relação a cada um dos termos especificados na consulta. Nesta tarefa, utilizou-se a mesma medida de similaridade empregada na avaliação de similaridade dos caminhos (distância de Levenshtein). Cada avaliação é comparada a um limiar. Caso o resultado da medida de similaridade seja

14

http://www.dcs.shef.ac.uk/~sam/simmetrics.html

45

superior ao limiar definido, o valor do componente do vetor referente ao termo analisado é atualizado com o valor do seu peso. Para o cálculo deste peso é utilizado o método tf-idf, onde o termo tf será o valor da freqüência da palavra corrente na consulta, enquanto que o dado correspondente ao termo idf pode ser obtido através do campo do registro que armazena a freqüência global da palavra.

Durante o percorrimento do vocabulário realizado para a construção do vetor consulta, cada um dos registros recuperados é armazenado. Esta característica é relevante para a tarefa de construção dos vetores documento. Através da lista de ocorrências associada a cada registro, é possível determinar quais os documentos que contém os termos especificados na consulta. Desta forma, realiza-se a construção de n vetores, onde n representa o número de documentos diferentes que estão presentes no conjunto de registros retornados. Sendo assim, elimina-se a necessidade de construção de vetores de documentos que certamente teriam um valor muito baixo, ou nulo, de relevância em relação à consulta.

Para a realização do cálculo de similaridade entre o vetor consulta e cada um dos vetores documento, é utilizada a medida do cosseno do ângulo entre estes vetores. Contudo, aplicou-se uma simplificação deste cálculo através da normalização dos vetores. Sendo assim, após o processo de construção dos vetores envolvidos nesta tarefa, estes mesmos vetores são normalizados tornando possível o cálculo da similaridade através da aplicação do produto interno entre eles. Informações relativas à implementação da tarefa de processamento da consulta podem ser encontradas no Anexo 1.

5.5. Classificação dos Resultados (Ranking)

Sistemas de IR modernos possuem uma maneira para realizar a classificação dos resultados. A classificação tem como objetivo a ordenação dos objetos recuperados de tal forma que os objetos considerados de maior relevância em relação à consulta submetida pelo usuário sejam exibidos no topo da lista. Isto significa que, não importa o número de objetos retornados, o usuário terá que revisar poucos deles, pois conforme ele avança na lista de resultados, a relevância dos objetos diminui.

Usualmente, a classificação de resultados é feita em relação entre eles mesmos. Isto é, o valor de relevância atribuído a um objeto reflete a sua importância dentro do conjunto de objetos recuperados para a consulta submetida. Em outras palavras, se o valor de relevância de um objeto para uma dada consulta é comparado com o valor do mesmo objeto para uma consulta diferente, na maioria dos casos os valores de relevância atribuídos são diferentes. Da mesma forma, o mesmo objeto em uma base de dados diferente gera um valor de relevância diferente. A partir disso pode-se concluir que não existe uma maneira fixa de se atribuir um valor de relevância para um objeto retornado, mas que este valor varia de acordo com a consulta e com a base de dados utilizada.

Existem diferentes maneiras para cálculo da relevância de um documento. Neste trabalho, optou-se pelo uso do valor de similaridade inerente

46

ao modelo vetorial utilizado. Porém, como a linguagem de consulta possibilita a definição de construtos estruturais, isto é, permite ao usuário definir restrições em relação à estrutura dos objetos que devem ser retornados, utilizou-se também a medida de similaridade entre a informação estrutural definida pelo usuário na consulta e o dos objetos retornados.

Desta forma, obtém-se que o cálculo final da relevância de um documento em relação à consulta, considerando que a consulta contenha construtos estruturais e de conteúdo, é dado pela seguinte fórmula:

"#6,��,�- = $ + $&%8�� , �9 + %�+8!��ℎ.; , !��ℎ193 ∗ 100

Para o caso no qual o usuário não define nenhum construto estrutural, elimina-se o termo referente a este dado e obtém-se a relevância através da fórmula:

"#6,��,�- = $ + $&%8�� , �92 ∗ 100

5.6. Avaliação do mecanismo de IR

Nesta seção, serão apresentados os testes experimentais que foram efetuados com a finalidade de avaliar aspectos do mecanismo proposto. Esta seção é subdividida em duas subseções. Na primeira são analisadas características de tempo e espaço necessário para a geração e para o armazenamento da estrutura de índice. Na segunda parte são apresentados os resultados de desempenho considerando as medidas utilizadas na área de recuperação de informação.

Os experimentos foram conduzidos em um computador rodando o sistema operacional Ubuntu versão 7.04 com um processador Pentium Core 2 Duo e 2 Gb de memória principal. O protótipo foi desenvolvido utilizando-se a linguagem de programação Java versão Standard Edition 6 e a ferramenta de desenvolvimento NetBeans 6.1.

5.6.1. Geração de Índices

Para os experimentos em relação ao tamanho do índice e ao tempo de indexação de documento, foi gerada uma base de dados artificial. A base foi gerada através da utilização do benchmark XMark15 pela ferramenta xmlgen. Esta ferramenta possibilita a geração de documentos XML bem formados e válidos. Os arquivos gerados pelo benchmark XMark são intensivos em conteúdo e possuem uma estrutura com poucos níveis. Outro fato importante é a capacidade de escalabilidade dos documentos gerados, isto é, a capacidade de gerar documentos que variam entre poucos bytes a até gigabytes de tamanho. O conjunto gerado de documentos XML é composto por quatro arquivos. A Tabela 5.5 mostra as informações a respeito do conjunto de documentos.

15

http://monetdb.cwi.nl/xml/

47

Documento Tamanho Número de Elementos

documento1.xml documento2.xml documento3.xml documento4.xml

100 Kb 500 Kb 1 Mb

10 Mb

1507 7466

15050 146708

Tabela 5.5 – Dados dos documentos da coleção

Para cada documento da coleção, foi gerado um índice. Os dados referentes ao processo de criação do índice de cada documento estão disponíveis na Tabela 5.6.

Documento Tempo de Indexação

Tamanho do Índice

Elementos Indexados

Entradas no Índice

documento1.xml documento2.xml documento3.xml documento4.xml

1 segundo 7 segundos

15 segundos 191 segundos

400 Kb 1,5 Mb 3 Mb

30 Mb

124 515

1025 10607

4214 7297 8633

10696

Tabela 5.6 – Dados sobre os índices gerados para a coleção

Como pode ser observado pelos dados da Tabela 5.6, o espaço ocupado pelos índices gerados é maior que o ocupado pelos documentos da coleção. Este fato se deve a estrutura adotada para o índice e a não utilização de técnicas de compactação, como por exemplo, compactação de prefixos. Cada entrada do índice armazena um termo do documento, a freqüência global associada ao termo e a sua lista de ocorrências. Para cada ocorrência é armazenado o identificador do elemento e a freqüência associada ao termo para a respectiva ocorrência. Desta forma, fica evidente a necessidade de um maior espaço de armazenamento para o índice, tendo em vista a necessidade de armazenamento dos n valores de freqüência associados a cada termo. A figura 5.3 ilustra o tamanho dos documentos e do índice associado a cada um deles. A seguir, a Figura 5.4 apresenta as medidas de tempo necessárias para a criação de cada um dos índices. Através destas medidas pode-se observar o aumento do tempo necessário para o processo de indexação acompanhando o crescimento do tamanho do documento a ser indexado.

Figura 5.3 – Tamanhos dos documentos e índices

48

Figura 5.4 – Tempo para criação dos índices

5.6.2. Recuperação de Informação

Para a avaliação de mecanismos de recuperação de informação, existem duas medidas específicas que devem ser observadas, são elas revocação e precisão. Nesta tarefa de análise destas medidas, utilizou-se uma base de dados diferente da empregada nos experimentos anteriores. Esta opção por uma mudança na base de dados é justificada na seção 5.6.2.1.

5.6.2.1. Base de Dados

Optou-se pela utilização do benchmark XBench[19] que, assim como o XMark, possui uma ferramenta para geração de documentos XML. Contudo, o XBench utiliza um template para a geração do documento. Sendo assim, foi especificado um template para que a base gerada tivesse a sua estrutura conhecida.

A utilização de uma base de dados com estrutura conhecida é necessária à medida que esta base é sintética (gerada automaticamente). Neste sentido, o número de elementos relevantes para uma determinada consulta não é conhecido. Além disso, a análise manual da coleção para determinação de elementos relevantes em relação às consultas não é viável tendo em vista a aleatoriedade do texto contido nos documentos. Desta forma, através da informação estrutural é feita a determinação do conjunto de elementos relevantes.

Considerando a natureza aleatória do conteúdo da coleção gerada, foi necessária a utilização de uma metodologia para a determinação dos elementos relevantes para cada consulta. Optou-se pela utilização da informação estrutural para determinação da relevância de um documento. Sendo assim, elementos relevantes devem conter pelo menos um dos termos especificados na consulta e, além disso, devem estar relacionados a um elemento que possua uma estrutura semanticamente equivalente à que foi especificada na consulta.

Além do arquivo gerado pelo benchmark XBench, também optou-se pela utilização de um documento XML bem conhecido chamado SigmodRecord16. Neste documento são encontradas informações sobre artigos da área de

16

http://www.sigmod.org/record/xml/

49

tecnologia da informação e os autores relacionados com cada artigo. A Tabela 5.7 apresenta estatísticas dos documentos utilizados.

Documento Tamanho Número de Elementos

Collection.xml 4 Mb 43976

SigmodRecord.xml 500 Kb 9354

Tabela 5.7 – Informações da coleção de documentos

Considerando-se que o objetivo deste trabalho é a recuperação de elementos de um documento XML e não propriamente do documento, a quantidade de elementos torna-se mais relevante do que a quantidade de documentos presentes na coleção.

5.6.2.2. Especificação das consultas

Após a definição da base de dados a ser empregada para a realização das avaliações, é necessário definir-se um conjunto de consultas a serem processadas no experimento. A Tabela 5.8 e a Tabela 5.9 apresentam as consultas que foram submetidas ao mecanismo de recuperação de informação. Estas consultas foram especificadas através da utilização da linguagem MicroXPath que é disponibilizada pelo mecanismo de IR.

MicroXPath

Q1

Q2

Q3

Q4

["database","evaluation"] ["information","text","retrieval"] /dblp/article/author["John","McPherson"] /dblp/article/title["query","optimization"]

Tabela 5.8 – Consultas executadas no documento SigmodRecord.xml

MicroXPath

Q5

Q6

Q7

Q8

/SigmodRecord/issues/issue/articles/article/authors/author["Machado"] /dblp/article/author["Machado"] /SigmodRecord/issues/issue/articles/article/title["dependecy","pattern"] ["Paris","Venice","Berlin"]

Tabela 5.9 – Consultas executadas no documento Collection.xml

As consultas Q1 e Q2 têm como objetivo recuperar elementos que contenham pelo menos um dos termos especificados na consulta. Estas duas consultas são utilizadas para apresentação dos resultados de precisão e revocação alcançadas pelo mecanismo utilizando o documento SigmodRecord.xml como coleção de dados. Por outro lado, as consultas Q3 e Q4 foram executadas para comprovar a capacidade do método de casamento aproximado de dados estruturais considerando consultas especificadas para um determinado domínio. Ambas as consultas Q3 e Q4 foram especificadas com base na estrutura do documento DBLP e retornaram resultados corretos durante as suas execuções no documento SigmodRecord.

O segundo conjunto de consultas tem como objetivo demonstrar o funcionamento do mecanismo considerando uma coleção contendo uma quantidade maior de dados e também de destacar o funcionamento do processo adotado para expansão da consulta.

50

5.6.2.3. Resultados

A seguir são apresentados os resultados para as consultas especificadas durante a avaliação do mecanismo. Conforme especificado na seção sobre a especificação das consultas a serem utilizadas durante os experimentos, a Figura 5.5 apresenta os gráficos de revocação versus precisão para as consultas Q1 e Q2 com o objetivo de quantificar o desempenho do mecanismo em relação a estas duas medidas.

(a) (b)

Figura 5.5 – (a) Gráfico revocação versus precisão para a consulta Q1 (b) Gráfico revocação versus precisão para a consulta Q2

A utilização da coleção SigmodRecord para a avaliação das medidas de revocação e precisão deve-se ao fato de que este é um documento relativamente pequeno e, sendo assim, é possível realizar a análise do documento com a finalidade de obter a informação do número de elementos relevantes existentes, tornando assim possível o cálculo das medidas de avaliação que foram obtidas durante os experimentos.

Além dos gráficos de precisão versus revocação, a Tabela 5.10 apresenta os valores para as medidas de revocação e MAP considerando o conjunto de elementos recuperados.

MAP Revocação

Q1 0.77 1

Q2 0.38 0.88

Q3 1 1

Q4 0,26 0.9

Valor Final 0,6 0,94

Tabela 5.10 – Valores de MAP e revocação para o primeiro conjunto de consultas

A seguir são apresentados os resultados obtidos para o segundo conjunto de consultas. Na análise realizada são destacados aspectos sobre a precisão do conjunto de elementos retornados. A Tabela 5.11 apresenta informações sobre os resultados para as consultas especificadas para avaliação executadas sobre o documento Collection.xml.

Como a quantidade de documentos relevantes presentes na coleção para uma determinada consulta não pode ser estipulada, inviabiliza-se o cálculo da medida de revocação. Desta forma, a Tabela 5.11 apresenta aspectos sobre a precisão do conjunto de elementos retornados, adotando-se a definição de relevância definida em 5.6.2.1.

51

Dados sobre as consultas

Q5,

Q6

Tempo execução: 223 ms

Elementos retornados: name

city

abstract

biography

793

241 130 212 210

Relevância Média: 66%

Precisão: 30%

Q7 Tempo execução: 363 ms

Elementos retornados: biography

abstract

1932

1387 545


Precisão: 28%

Q8 Tempo execução: 2980 ms

Elementos retornados: title

country city

name

abstract

biography

5053

20 51 61 87 1342 3492


Precisão: 1%

Tabela 5.11 – Resultados para as consultas avaliadas

Para exemplificar o processo de determinação de elementos relevantes do conjunto retornado, toma-se como exemplo a consulta Q5. Executando-se esta consulta sobre a base de dados, são retornados 793 elementos. Dentre todos os elementos retornados, 241 possuem o identificador de elemento name associado ao texto “Machado”. Sendo assim, considera-se que o número de elementos relevantes no conjunto recuperado é 241. No caso da consulta Q5, através da análise dos termos consultados pode-se inferir que o usuário esteja interessado em cidades que contenham um ou mais termos do conjunto “Paris”, “Venice” e “Berlin”. Assume-se que uma consulta equivalente seria //city[“Paris”, “Venice”, “Berlin”]. A inclusão desta consulta nos experimentos busca demonstrar a importância da exploração da informação estrutural presente em documentos XML e como esta informação pode melhorar a qualidade do conjunto de elementos retornados.

Através dos experimentos realizados constata-se o funcionamento do mecanismo de recuperação de informação, e também se obtêm dados quantitativos em relação ao seu desempenho. Estes resultados obtidos são importantes para futuras avaliações do mecanismo proposto em relação a demais mecanismos semelhantes.

52

6. Conclusão

Como resultado deste trabalho, desenvolveu-se um mecanismo de recuperação de informação integrado ao gerenciador de banco de dados XTC. Apresentou-se a importância da área de recuperação de informação e como ela facilita a tarefa de descobrimento de informação. Da mesma forma, foram discutidos os subprocessos envolvidos em um processo de IR e para cada um deles apresentou-se uma discussão sobre o seu funcionamento.

O mecanismo de IR proposto neste trabalho é baseado em um índice. Este índice é organizado em uma lista invertida armazenada em uma estrutura de árvore. O resultado é uma estrutura capaz de resolver facilmente consultas que envolvam restrições de conteúdo e de estrutura do documento. Nenhum tipo de otimização foi utilizada para a construção do índice. Contudo, são sugeridas algumas, como por exemplo, compressão de prefixos, que poderiam ser facilmente incluídas durante a tarefa de indexação. Para a tarefa de construção do índice, o mecanismo se concentra na indexação do conteúdo e, sendo assim, consultas que envolvam apenas restrições estruturais não são suportadas. Neste sentido, construtos estruturais têm como função auxiliar no processo de classificação dos resultados, já que uma medida de similaridade é obtida através desse dado e utilizada no cálculo final do valor de relevância do documento. A informação estrutural armazenada no índice sobre o termo indexado é o deweyID associado ao elemento no qual o termo ocorre. DeweyID é um esquema de rotulação de nodos de arquivos XML e contém a informação completa sobre a estrutura do arquivo um elemento. Esta informação permite a reconstrução do caminho completo, desde o nodo raiz até o nodo no qual o termo ocorre, sem a necessidade de realizar qualquer acesso ao documento original.

Também foi discutida a importância da classificação dos resultados em um mecanismo de IR e como esta tarefa facilita a tarefa do usuário de percorrer o conjunto de elementos retornados. A tarefa de classificação tem como objetivo a organização dos resultados de acordo com o valor de relevância atribuído a cada um dos objetos do conjunto recuperado. Destacaram-se os pontos considerados para a avaliação da relevância de um documento em relação à consulta submetida e a metodologia para cálculo da relevância que foi utilizada. De fato,a classificação dos resultados é um dos fatores mais importantes na avaliação da precisão de um mecanismo de IR.

Ainda como parte deste trabalho, desenvolveu-se uma linguagem para a realização de consultas. Esta linguagem é um subconjunto da linguagem XPath é foi criada com o objetivo de ser uma linguagem de fácil entendimento enquanto mantendo ainda determinado poder de expressividade da linguagem

53

XPath. Apresentou-se a gramática que fundamenta a linguagem e as ferramentas utilizadas durante o processo de desenvolvimento. Finalmente foi discutido o processo de avaliação da consulta, começando pela sua decomposição em tokens, passando pela validação destes tokens em relação à regras de construção e finalizando com a criação de um objeto “consulta” o qual é processável pelo mecanismo.

Por fim, foram apresentados aspectos de avaliação e como estes aspectos foram aplicados para cálculo de medidas como desempenho, necessidade de espaço para armazenamento, revocação e precisão. Estas medidas obtidas a partir da avaliação do mecanismo proposto são importantes, pois fornecem dados quantitativos a respeito deste mecanismo.

A principal contribuição deste trabalho é a integração de um mecanismo de recuperação de informação ao gerenciador de banco de dados XML nativo XTC. Além de prover uma ferramenta básica de recuperação de informação, este mecanismo serve como ponto inicial para a realização de pesquisas na área de recuperação de informação em bases de dados XML. Além disso, através dos resultados quantitativos obtidos, pode-se empregar este mecanismo como base para futuras avaliações em relação a novas implementações que venham a ser realizadas.

6.1. Trabalhos Futuros

Ainda existem algumas questões a serem resolvidas no contexto do trabalho proposto. Um ponto importante em relação a mecanismos de IR que se propõem a executar recuperação em bases de dados XML é a possibilidade de recuperação baseada apenas em construtos estruturais. A estrutura de índice utilizada atualmente não suporta consultas puramente estruturais. Apesar da possibilidade oferecida ao usuário de definir um construto estrutural na consulta, esta informação não é levada em conta pelo mecanismo de busca. Neste mecanismo de IR, optou-se pelo foco na pesquisa por conteúdo onde o construto estrutural tem apenas utilidade para o processo de classificação dos resultados. Uma melhoria importante seria o desenvolvimento de um índice capaz de capturar informações referentes à estrutura e ao conteúdo do arquivo sem a necessidade de utilização de dois índices para isso, como é proposto no esquema XICS. Tal melhoria reduziria a necessidade de espaço de armazenamento para o índice o que é um fato importante considerando o tamanho dos documentos atuais que necessitariam ser indexados.

Diferentes aplicações freqüentemente têm diferentes necessidades de classificação dos seus resultados. Enquanto para um domínio de aplicação uma estratégia de classificação fornece um resultado apropriado, para outros domínios esta mesma estratégia pode gerar resultados não satisfatórios. Uma extensão interessante seria a inclusão de diferentes algoritmos de classificação permitindo ao usuário selecionar entre eles o mais apropriado considerando a base de dados e a aplicação que ele estiver utilizando. A utilização de algoritmos de classificação auxilia o usuário na tarefa de avaliação do conjunto de objetos retornados, porém, utilizando-se um algoritmo de classificação adequado à aplicação e aos dados, do ponto de vista do usuário, a qualidade do conjunto retornado é ainda maior. Neste sentido, fornecer ao usuário a

54

capacidade de escolha de maneira que ele possa selecionar o algoritmo que melhor reflete a sua necessidade é uma grande melhoria.

O mecanismo exige que os documentos sobre os quais deseja-se executar uma consulta estejam previamente indexados. Além disso, caso o documento venha a ser alterado após a criação do seu respectivo índice, esta estrutura previamente construída não mais reflete o estado atual do documento. Desta forma, é interessante o desenvolvimento de um índice dinâmico, isto é, que seja atualizado de acordo com as alterações realizadas no documento evitando assim a necessidade do percorrimento de todo o documento novamente. Ainda em relação à estrutura do índice, mais uma melhoria sugerida seria a inclusão da informação de posição do termo dentro do documento no qual ele ocorre. A posição de um termo é dada de acordo com o número de palavras que compõe o documento. Para cada palavra, seria armazenada a posição na qual aquela palavra aparece no texto (por exemplo, a posição i seria associada a i-ésima palavra do texto). Esta informação de posição da palavra pode ser utilizada como mais um parâmetro na determinação da relevância de um documento. Para isso, leva-se em conta a informação de disposição dos termos da consulta, isto é, a ordem dos termos, e esta informação é então comparada com a ordem com que os termos aparecem no documento recuperado. Documentos nos quais os termos apareçam na mesma ordem definida na consulta receberiam um valor de relevância maior em relação aos demais.

Um ponto importante para a validação de um mecanismo de recuperação de informação em XML é a condução de testes sobre bases de dados contendo documentos bem conhecidos como os documentos DBLP e SIGMOD Record entre outros. Contudo, levando em conta a proposta do mecanismo desenvolvido em recuperar apenas elementos do documento, sugere-se a utilização de uma base de dados já avaliada neste modelo de recuperação. Sendo assim, recomenda-se a execução de experimentos sobre a base de dados do INEX17. A coleção de dados consiste em aproximadamente 12.000 documentos XML totalizando 500 megabytes de dados. Também podem ser obtidas as consultas que foram realizadas sobre esta base de dados e os resultados esperados para cada uma delas.

Finalmente, sugere-se uma aplicação para este modelo de recuperação de informação integrado a uma ferramenta de busca na internet. Grande parte do conteúdo disponibilizado na internet é através da utilização de documentos semi-estruturados. Conforme citado no texto introdutório deste trabalho, os exemplos mais conhecidos de ferramentas de IR são os mecanismos de busca. Estes mecanismos possuem uma sofisticada estrutura de índices sobre os quais as buscas são executadas. Os objetos resultantes da tarefa de busca são então classificados de acordo com a sua relevância em relação à consulta, através da utilização de uma heurística. Cada mecanismo de busca possui a sua heurística para a realização desta tarefa e esta heurística é uma das características que difere um mecanismo do outro. Contudo, os objetos retornados por estes motores de busca são, de maneira geral, muito semelhantes. A informação recuperada por eles são apontadores para páginas

17

http://inex.is.informatik.uni-duisburg.de/

55

da Web. Estes apontadores normalmente vêm associados a um trecho do texto do documento referenciado por eles. Contudo, a decisão a respeito do trecho a ser exibido é feita com base no conteúdo do documento. A abordagem proposta tem como objetivo a utilização da informação estrutural do documento para a determinação do trecho a ser recuperado. Além disso, ao invés da recuperação de apontadores para documentos, sugere-se que o mecanismo seja capaz de homogeneizar a estrutura dos elementos retornados com o objetivo de exibi-los diretamente ao usuário. Desta forma, a tarefa do usuário de navegação através dos apontadores poderia ser evitada facilitando o acesso à informação recuperada.

Entretanto, a integração de um mecanismo de recuperação de elementos em uma máquina de busca não é uma tarefa trivial. Além dos desafios comuns encontrados atualmente para a tarefa de recuperação de informação na Web, como por exemplo, o alto grau de volatilidade dos dados devido à facilidade de inclusão e remoção, existem outros desafios que devem ser levados em conta para a utilização desta técnica. Um deles é a heterogeneidade dos dados, isto é, documentos que contém dados sobre o mesmo assunto, porém são descritos através de estruturas completamente diferentes. Outro desafio é em relação à qualidade dos dados. Esta questão refere-se à utilização de estruturas que não são adequadas para a descrição dos dados contidos no documento e também a erros estruturais na construção do documento. Além disso, mais um fator importante é a definição de uma heurística para determinar qual elemento deve ser retornado.

56

REFERÊNCIAS

[1] World Wide Web Consortium. Extensible Markup Language (XML), 1996-2003. Disponível em: http://www.w3.org/XML/. [2] World Wide Web Consortium, Standart Generalized Markup Language (SGML), 1995-2004. Disponível em: http://www.w3.org/MarkUp/SGML/. [3] T. Härder, XML Databases and Beyond – Plenty of Architectural Challenges Ahead, in ADBIS, 2005. [4] World Wide Web Consortium, Document Object Model (DOM), 2005-2008. Disponível em: http://www.w3.org/DOM/. [5] D. Megginson, Simple API for XML (SAX), 2001-2004. Disponível em: http://www.saxproject.org/. [6] World Wide Web Consortium, XML Path Language (XPath), 1999. Disponível em: http://www.w3.org/TR/xpath. [7] C. F. Goldfarb and P. Prescod, The XML Handbook. 3rd ed. Rio de Janeiro: Prentice-Hall do Brasil, 2001. [8] World Wide Web Consortium, XQuery 1.0: An XML Query Language, 2007. Disponível em: http://www.w3.org/TR/xquery. [9] Princeton University, WordNet lexical database for the English language, 2006. Disponível em: http://wordnet.princeton.edu/. [10] T. Parr, ANTLR – Another Tool for Language Recognition, 2006. Disponível em: http://www.antlr.org. [11] T. Amagasa, L. Wen and H. Kitagawa, Proximity Search of XML Data Using Ontology and XPath Edit Similarity, in DEXA, 2007. [12] T. Shimizu and M. Yoshikawa, Full-Text and Structural Indexing of XML Documents on B+-Tree*, in DEXA, 2005. [13] M. P. Haustein, T. Härder, C. Mathis and M. Wagner, DeweyIDs – Fine-Grained Management of XML Documents, in SBBD, 2006.

57

[14] R. Baeza-Yates e B. Ribeiro-Neto, Modern Information Retrieval. New York: ACM Press, 1999. [15] M. W. Berry and M. Browne, Understanding Search Engines Mathematical Modeling and Text Retrieval. 2nd ed. Philadelphia: Society for Industrial and Applied Mathematics. [16] J. Zobel, A. Moffat and K. Ramamohanarao, Inverted files versus signature files for text indexing, in TODS, 1998. [17] Q. Li and B. Moon, Indexing and Querying XML Data for Regular Path Expressions, in VLDB Conference, 2001. [19] XBench – A Family of Benchmarks for XML DBMSs, 2003. Disponível em: http://softbase.uwaterloo.ca/~ddbms/projects/xbench/. [20] J. M. Bremer and M. Gertz, Integrating document and data retrieval based on XML, in VLDB Journal, 2005. [21] A. Singhal, Modern Information Retrieval: A Brief Overview, in Bulletin of the IEEE Computer Society Technical Committee on Data Engineering, 2001.

58

ANEXO 1 – Implementação do mecanismo

Este anexo tem como objetivo apresentar aspectos sobre a implementação do mecanismo de recuperação de informação. Serão apresentados diagramas que detalham as classes e, para cada uma delas, serão explicitadas informações consideradas relevantes para o entendimento do funcionamento do mecanismo.

A.1 Diagramas de classe

A Figura A.1 apresenta as classes envolvidas no processo de indexação do documento XML enquanto que a Figura A.2 apresenta as classes envolvidas no processo de avaliação das consultas. A seguir, um breve esclarecimento sobre cada uma das classes desenvolvidas é realizado.

A.1.1. Classe: IRIndexBuilderController

Classe responsável pelo controle do processo de indexação. Por meio do método indexFragment(String strText, String strObjectID) é indexado o fragmento do documento associado ao identificador de elemento strObjectID. O fragmento de texto recebido através do parâmetro strText é submetido aos processos de análise léxica, eliminação de stopwords e stemming.

A.1.2. Classe: Stemmer

Classe encarregada da realização do processo de stemming.

A.1.3. Classes InvertedList, Record e Occurrence

Classes de modelo para a representação das estruturas lista invertida, registro e ocorrência respectivamente. Estas classes armazenam as informações extraídas do texto e que são posteriormente utilizadas pelo mecanismo de busca.

A.1.4. Classe: IRIndexFinderController

Classe responsável pelo controle do processo de avaliação de uma consulta.A consulta é submetida através do método find(String input). Em seguida a consulta passa pelo processo de validação (parsing) e, caso não ocorra nenhuma exceção, é gerado um objeto IRQuery que é então avaliado pelo mecanismo.

A.1.5. Classe: IRQuery

Modelo utilizado internamente pelo mecanismo para a representação da consulta submetida.

59

A.1.6. Classe: QueryVector

Modelo para a representação do vetor da consulta.

A.1.7. Classe: DocumentVector

Modelo para representação do vetor de um documento.

A.1.8. Classe: WordNetController

Classe responsável pelo acesso aos dados do dicionário WordNet. Através do método getSynsets(String word) é retornado um conjunto de sinônimos para o termo especificado pelo parâmetro word.

A.1.9. Classe: PathHelper

Classe responsável pelas operações envolvendo expressões de caminho. Esta classe também é encarregada de realizar a expansão da expressão de caminho submetida na consulta.

A.1.10. Classe: CoreFinder

Classe responsável pela criação dos vetores referentes à consulta e a cada um dos documentos.

60

Figura A.1 – Classes envolvidas no processo de indexação

61

Figura A.2 – Classes envolvidas no processo de avaliação de uma consulta