Um Processo Automático para Extração de Metadados de Documentos PDF Usando um Template XML

(1)

Um Processo Automático para Extração de Metadados de

Documentos PDF Usando um Template XML

∗∗∗∗

Edimar Manica1, Cristiano Roberto Cervi1, Renata de Matos Galante2

1_{Instituto de Ciências Exatas e Geociências – Universidade de Passo Fundo (UPF)} Bairro São José – BR 285 – Km 171 – 99001-970 – Passo Fundo – RS 2_{Instituto de Informática – Universidade Federal do Rio Grande do Sul (UFRGS)}

Caixa Postal 15.064 – 91.501-970 – Porto Alegre – RS – Brasil

edimarmanica@yahoo.com.br, cervi@upf.br, galante@inf.ufrgs.br

Resumo. Este artigo descreve uma proposta para extração de metadados de

documentos PDF. O extrator desenvolvido utiliza um template, representado por um arquivo XML, que possui a descrição dos metadados a serem extraídos do documento desejado. A partir do XML, o extrator executa uma série de passos para a localização dos metadados no documento indicado, sendo todo o processo realizado de forma automática, onde a única intervenção por parte do usuário é a construção do template XML.

Abstract. This paper presents a proposal for extracting metadata from PDF

documents. The developed extractor uses a template, represented in a XML document, which has the specification of the metadata to be extracted from the document. From the XML document, the extractor automatically executes a set of steps in order to find the metadata in a specified document, and user intervention is only necessary to build the XML document.

1. Introdução

Nos últimos tempos, a necessidade por ferramentas de pesquisa, filtragem e manipulação de informações relevantes, disponibilizadas em meio eletrônico, tornou-se essencial. Esta necessidade está presente em diversos contextos, desde ambientes empresariais, para a manipulação de dados em Data Warehouse, até instituições de pesquisa através da troca de produção científica. Neste cenário, a Web aparece como o principal veículo para troca e busca de informações. Ao contrário dos bancos de dados relacionais, informações neste meio apresentam uma estrutura fraca (os dados semi-estruturados) ou até inexistente (dados não semi-estruturados). O desafio atual é construir ferramentas que possibilitem a consulta e manipulação dos dados desta natureza.

Muito tem sido desenvolvido para a manipulação de dados semi-estruturados, principalmente arquivos HTML (Mecca 1998), (Laender et al. 2002), (Laender, Ribeiro-Neto e Da Silva 2002), (Silveira e Heuser 2001). A ferramenta Debye (Laender et al. 2002), (Laender, Ribeiro-Neto e Da Silva 2002), por exemplo, funciona de forma interativa, recebendo como entrada uma série de exemplos criados por usuários a partir de uma página de amostra. Dados estes exemplos, o sistema gera padrões (através do uso de wrappers) que permitem a extração de objetos de páginas similares. Apesar da

(2)

facilidade de uso, os resultados obtidos em alguns casos não são satisfatórios. Quando um wrapper é gerado, a partir de uma página de exemplo, este funciona adequadamente apenas para esta página, apresentando resultados equivocados quando aplicado a páginas similares. A ferramenta Araneus (Mecca 1998) se baseia no formalismo definido em Minerva (Crescenzi e Mecca 1998), utilizado para descrição de wrappers, que combina uma gramática declarativa com as características típicas de linguagens de programação procedimentais. É necessário grande conhecimento da estrutura da página e da linguagem Minerva para a construção de um wrapper para a ferramenta Araneus. O principal foco utilizado no desenvolvimento destas ferramentas é o suporte a dados representados em linguagens que possuem certa estrutura, como HTML.

A extração de dados não estruturados, normalmente, possui o suporte de modelos conceituais ou ontologias (Wessman, Liddle e Embley 2005), (Embley, Tao e Liddle 2005), para que o processo funcione. Neste caso, torna-se indispensável que a ontologia, ou o modelo conceitual, seja projetado de forma bastante completa para que, de fato, o processo seja executado de forma funcional.

Problemas na extração de dados oriundos de documentos PDF podem ser encontrados em diversas aplicações, inclusive em sistemas de bibliotecas digitais. Como tais sistemas armazenam o documento digital e precisam de informações sobre ele para que consultas possam ser executadas e apresentadas aos usuários, torna-se fundamental a extração de metadados específicos do documento armazenado para que as informações sejam geradas de maneira a satisfazer os critérios estabelecidos.

Neste artigo, é apresentado um processo de extração de metadados a partir de documentos sem estrutura, especificamente documentos PDF. Para isso foi desenvolvido o extrator de metadados denominado EMP (Extracting Metadata from PDF file). O processo faz uso de um documento XML, que funciona como um template, onde são especificados os campos de metadados que devem ser extraídos dos documentos. O processo é automático, sendo necessária a intervenção do usuário apenas na construção do template XML.

O artigo é organizado como segue. Na Seção 2 é apresentado o template XML usado pelo extrator. Na seção 3 é descrito o processo de extração dos metadados. A seção 4 apresenta um exemplo da utilização do processo. Alguns experimentos são mostrados na seção 5, bem como seus resultados. Finalmente, na seção 6 são descritas as considerações finais.

2. Template XML

Como os documentos PDF não possuem uma estrutura semântica, é necessário o uso de um documento XML, que funciona como um template, tornando possível que o extrator EMP identifique os metadados que devem ser extraídos em um documento. Isso torna possível que o processo de extração proposto seja utilizado para qualquer documento PDF, independente de seu layout de apresentação. Ressalta-se que o extrator foi construído para possibilitar um mecanismo semi-automático de auto-arquivamento em uma biblioteca digital de trabalhos de conclusão apresentado em Manica, Cervi e Dorneles (2007), ou seja, os elementos oferecidos para a especificação dos metadados são disponibilizados a partir da necessidade observada na extração dos metadados no contexto de trabalhos de conclusão de curso. Porém, isso não impede que o extrator seja utilizado para outros documentos PDF, apenas pode restringir algumas extrações, que ao serem observadas, serão implementadas no extrator. Contudo, todos os metadados de

(3)

documentos PDF que possam ser representados em um template XML com os elementos oferecidos pelo extrator serão extraídos, não importando a área do documento, desde trabalhos de conclusão a relatórios de faturamento de empresas.

O documento XML possui a estrutura apresentada na Figura 1 através de uma DTD (Document Type Definitions).

<!ELEMENT structure (coverSheet*, otherPages*)> <!ELEMENT coverSheet (metadata+)>

<!ATTLIST coverSheet page CDATA #REQUIRED>

<!ELEMENT metadata (position?, prefix?, suffix?, separator?)> <!ATTLIST metadata id CDATA #REQUIRED>

<!ELEMENT position (#PCDATA)>

<!ATTLIST position type (general|prefix) #REQUIRED> <!ELEMENT prefix (#PCDATA)>

<!ATTLIST prefix type (start|all_line) #REQUIRED> <!ELEMENT suffix (#PCDATA)>

<!ATTLIST suffix type (new_line|same_line) #REQUIRED> <!ELEMENT separator (#PCDATA)>

<!ELEMENT otherPages (metadata+)>

<!ATTLIST otherPages startPage CDATA #REQUIRED endPage CDATA #REQUIRED>

Figura 1 – Estrutura do arquivo XML.

A raiz do documento XML é representada por um elemento chamado structure, que é composto pelos elementos coverSheet e otherPages. O elemento coverSheet representa a página que contém metadados que são sempre encontrados em uma única página, e são representados através do elemento metadata. A identificação do número da página do documento PDF é feita através do atributo page. O elemento otherPages descreve um intervalo de páginas em que a ocorrência dos metadados não possui uma página específica, sendo possível sua distribuição dentro deste intervalo, definido através dos atributos startPage e endPage. No caso do elemento otherPages, os metadados também são representados dentro do elemento metadata. A separação entre os metadados que estão sempre em uma determinada página daqueles que podem estar em um intervalo de páginas, possibilita que sejam feitas estatísticas para verificar em qual dos casos encontra-se a maioria dos erros de digitação por parte do usuário. Da mesma forma, pretende-se destacar os metadados que devem estar em uma página específica, aos usuários que criarão seus documentos a partir do XML. Isso possibilitará que eles descrevam os metadados na página correta.

Para completar o documento XML, cada elemento metadata deve possuir um atributo id, que é usado para identificá-lo, cujo valor é o campo do metadado. Para que o metadado seja reconhecido no texto, é necessário identificar os limites de início e fim da string do metadado, que podem ser representados através da combinação dos seguintes elementos: (i) prefix, que define uma string que sempre antecede o metadado, e possui o atributo type que identifica se ela se encontra no início da mesma linha do metadado ou corresponde a toda a linha anterior; (ii) position, que conforme o valor de seu atributo type pode indicar a linha onde o metadado se encontra, ou qual o número de ocorrência da string que antecede o metadado, para o caso desta string se repetir na página, ou no intervalo de páginas onde se encontra o metadado em questão; (iii) suffix, que define uma cadeia de caracteres que sempre se encontra ao fim do metadado, e possui o atributo type para informar se este se

(4)

encontra na mesma linha do metadado ou no início da linha seguinte. Quando existe um metadado composto por um conjunto de valores, tal como as palavras-chave que descrevem um documento, utiliza-se o elemento separator para indicar o caractere usado na separação dos valores deste conjunto. Ressalta-se que não é necessário definir todos esses elementos citados, mas é necessário no mínimo para cada metadado definir um elemento position identificando uma posição fixa ou um elemento prefix identificando onde o metadado inicia. Caso não seja definido um elemento suffix o extrator entende o fim da linha como sufixo.

3. Processo de Extração dos Metadados

O processo como um todo inicia com a interpretação do arquivo XML, como apresentado na Figura 2.

Figura 2 – Processo de extração dos metadados.

Inicialmente, o arquivo XML é lido (1), a fim de validar a existência de elementos que, para serem corretamente usados, necessitam de outros. Por exemplo, um elemento position, tendo o atributo type com valor prefix , define o número de ocorrência de um prefixo e necessita a ocorrência do elemento prefix, cujo valor indica o prefixo de um metadado. Em seguida, o validador envia o documento XML válido ao coletor de informações (2), que deve separar os campos de metadados em duas partes: aqueles encontrados em uma única página, e aqueles encontrados em um intervalo de páginas. As informações coletadas, e o documento PDF, servem de entrada para o EMP, que extrai os metadados descritos nos elementos coverSheet e otherPages.

(5)

Para cada elemento coverSheet, e para cada elemento otherPages, especificados no arquivo XML, os seguintes procedimentos são necessários: (i) transformação da página referente ao elemento coverSheet em um arquivo TXT (3), e conversão do intervalo de páginas referente ao elemento otherPages em um arquivo TXT (5). Ambos os procedimentos são executados com o auxílio das bibliotecas PDF BOX1 e FONT BOX2, que delimitam o que é texto e o que são elementos de formatação; (ii) extração de metadados, a partir do arquivo TXT usado como entrada para o extrator (4 e 6), através da leitura do arquivo TXT e extração dos metadados. Em seguida, o conteúdo extraído é associado ao metadado correspondente.

Depois de concluída a etapa de extração de todos os metadados contidos em todos os elementos coverSheet e otherPages, os resultados são integrados a fim de montar a resposta final que contém todos os metadados extraídos.

4. Exemplificando a Extração

Para entender melhor o funcionamento do extrator, é apresentado um exemplo a partir do template XML observado na figura 3.

<prefix type="start">AVALIADOR: PROF.| AVALIADOR: </prefix>

<prefix type="start">AVALIADOR: PROF.| AVALIADOR: </prefix>

</coverSheet>

<otherPages startPage="4" endPage="10"> <metadata id="resumo"> <prefix type="allLine">RESUMO</prefix> <suffix type="newLine">PALAVRAS-CHAVE:|PALAVRAS-CHAVE</suffix> </metadata> <metadata id="palavras_chave"> <prefix type="start">PALAVRAS-CHAVE:|PALAVRAS- CHAVE</prefix> <separator>,</separator> <suffix type="sameLine">.</suffix> </metadata> </otherPages> </structure>

Figura 3 – Template XML de exemplo.

1_{Disponível em http://www.pdfbox.org} 2_{Disponível em http://www.fontbox.org}

(6)

Para o template apresentado na figura 3 o extrator procura na terceira página os seguintes metadados:

• “instituição”: inicia no primeiro caractere da primeira linha e termina ao encontrar o final desta mesma linha.

• “título”: inicia na quarta linha e termina no final da linha que antecede a linha que inicia “ALUN”.

• “avaliador1”: inicia na primeira linha que começa por “AVALIADOR: PROF.” ou por “AVALIADOR:” e termina no fim desta mesma linha. • “avaliador2”: inicia na segunda linha que começa por “AVALIADOR:

PROF.” ou por “AVALIADOR:” e termina no fim desta mesma linha. O extrator também procura da página 4 a página 10 os seguintes metadados:

• “resumo”: inicia na linha sucessora à linha que contém única e exclusivamente a string “RESUMO” e termina na linha que antecede a linha que inicia por “PALAVRAS-CHAVE:” ou por “PALAVRAS-CHAVE”. • “palavras_chave”: inicia na linha que começa por “PALAVRAS-CHAVE:”

ou por “PALAVRAS-CHAVE” e termina ao encontrar um “.”. Além disso, quebra os metadados extraídos em n metadados a cada ocorrência de uma “,” ou “ e “(\\s representa espaço em branco).

O extrator é case insensitive, mas será implementado um elemento que permite diferenciar maiúsculas de minúsculas.

O caractere “|” separa as opções. Uma vez que o extrator não usa busca por similaridade é necessário definir todas as opções possíveis. Também, ressalta-se a importância da ordem das opções, as quais indicam a ordem que será pesquisada, logo deve-se especificar primeiro as opções de maior tamanho. Por exemplo, se for definido “PALAVRAS-CHAVE” antes de “PALAVRAS-CHAVE:” ao comparar a linha “PALAVRAS-CHAVE: banco de dados, ontologia.” com “PALAVRAS-CHAVE” o extrator encontrará a combinação e começará a extrair a partir do caractere sucessor, ou seja, extrairá o “:” como parte do metadado.

5. Experimentos e Resultados

Para validar o processo, primeiramente, o extrator foi incorporado no mecanismo de auto-arquivamento da BDTC3 (Biblioteca Digital de Trabalhos de Conclusão). Foram realizados 64 testes, sendo que cada um deles consiste na submissão de um trabalho de conclusão, no formato PDF, para o auto-arquivamento da BDTC. Após este processo de submissão, o extrator executa seu trabalho, verificando se os metadados que foram extraídos condizem com o esperado.

Os 13 primeiros testes foram realizados com o template XML apresentado na figura 4.

3_{Disponibiliza os trabalhos de conclusão dos cursos de graduação e pós-graduação da área de informática}

(7)

<structure> <coverSheet page="3"> <metadata id="instituicao"> <position type="general">1</position> </metadata> <metadata id="unidade"> <position type="general">2</position> </metadata> <metadata id="curso"> <position type="general">3</position> </metadata> <metadata id="titulo"> <position type="general">4</position> <suffix type="newLine">ALUN</suffix> </metadata> <metadata id="aluno"> <prefix type="start">ALUNO:|ALUNA:</prefix> </metadata> <metadata id="orientador">

ORIENTADORA:</prefix> </metadata>

AVALIADORA:</prefix>

AVALIADORA:</prefix> <position type="prefix">2</position> </metadata> <metadata id="areas"> <prefix type="start">ÁREAS:|ÁREA:</prefix> <separator>,</separator> <suffix type="sameLine">.</suffix> </metadata> </coverSheet>

<otherPages startPage="4" endPage="10"> <metadata id="resumo"> <prefix type="allLine">RESUMO</prefix> <suffix type="newLine">PALAVRAS-CHAVE:|PALAVRAS CHAVE:|PALAVRAS-CHAVE|PALAVRAS CHAVE</suffix> </metadata> <metadata id="palavras_chave"> <prefix type="start">PALAVRAS-CHAVE:|PALAVRAS CHAVE|PALAVRAS-CHAVE|PALAVRAS CHAVE</prefix> <separator>,</separator> <suffix type="sameLine">.</suffix> </metadata> </otherPages> </structure>

Figura 4 – Template XML usado em testes.

Dos 13 trabalhos de conclusão submetidos no primeiro teste, 10 foram extraídos com sucesso. Em um deles a última palavra-chave foi extraída de forma errada, pois as palavras-chave não terminavam com o sufixo definido. Em outro o título e o curso foram extraídos incorretamente, pois estes possuem especificação de posição fixa e o

(8)

criador do documento adicionou o número da página no cabeçalho da página, contando como uma linha, logo os metadados estariam uma linha abaixo do especificado. Finalmente, em outro documento o arquivo criado e convertido para PDF no Windows e submetido ao auto-arquivamento da BDTC, que roda em Linux, teve problemas com a codificação do PDF e não reconheceu os caracteres com acento. O processo já está sendo alterado para atender esta última situação.

No segundo teste foram realizadas 51 submissões com um template XML mais simples, conforme apresentado na figura 5.

<prefix type="start">PALAVRAS-CHAVE:|PALAVRAS CHAVE:|PALAVRAS - CHAVE:|PALAVRAS-CHAVE | PALAVRAS CHAVE

</prefix> <separator>,|\\se\\s</separator> <suffix type="same_line">.</suffix> </metadata> </otherPages> </structure>

Figura 5 - Template XML para encontrar palavras-chave

Dos 51 trabalhos de conclusão submetidos, 37 trabalhos foram extraídos corretamente, 4 não foram extraídos porque estavam protegidos, 4 foram extraídos incorretamente porque as palavras-chave não terminavam por “.”(suffix definido no XML), 1 foi extraído incorretamente pois seus metadados eram separados por um caractere diferente das opções de separador definidas no XML pelo elemento separator, 4 não possuíam palavras-chave logo nada foi extraído, e 1 não foi extraído por motivo ainda não identificado.

Ressalta-se que o erro na busca de um metadado não interfere à busca dos demais, porém foram contados nos testes como extraídos incorretamente, até mesmo, aqueles documentos que tiveram apenas um metadado extraído incorretamente.

6. Considerações Finais

Este artigo apresentou um processo de extração de metadados a partir de documentos PDF. O processo é automático, sendo que a única intervenção do usuário é a construção do template XML.

O extrator de metadados desenvolvido é implementado através de um processo facilmente executável, que faz uso de um template XML para a especificação dos metadados a serem extraídos. A principal contribuição está no fato do processo ser aplicável a qualquer documento PDF, e por não exigir a associação de estruturas mais complexas, como ontologias, para a execução da extração.

Os testes realizados com o extrator apresentaram resultados satisfatórios, uma vez que dos 64 documentos submetidos, 47 foram extraídos com sucesso, ou seja, aproximadamente 73,43%. Dos 17 documentos não extraídos ou extraídos incorretamente, 15 (88,23%) tiveram esta situação por erros de digitação do usuário que, por exemplo, esqueceu de colocar o ponto final (“.”) ao final das palavras-chave, ou

(9)

nem as escreveu, ou ainda protegeu o documento PDF contra cópia, impossibilitando a extração.

Após esta análise, pode concluir que o processo de extração foi bem sucedido durante os testes, pois houve 73,43% de acerto real. Se considerarmos a porcentagem de erros de responsabilidade do usuário, o índice de sucesso sobe para 96,87%.

Como trabalhos futuros, pretende-se utilizar funções de similaridade para identificação dos metadados nos documentos PDF. Por exemplo, em um texto referente a uma tese, o metadado orientador pode ter sido escrito de forma incorreta, tal como, orintador. Neste caso, o EMP não encontra o referido metadado no arquivo se apenas foi definido como prefixo orientador e definir todas as opções similares separando-as por “|” é possível, porém trabalhoso. Além disso, está sendo analisada a necessidade de construir um editor que facilite a construção do template XML, bem como permita uma melhor visualização de sua estrutura aos usuários que desejem construir seus documentos a partir do template.

Também se deseja fazer uma análise de outros extratores de características semelhantes, usando o mesmo estudo de caso, para verificar se os resultados alcançados com o EMP são realmente satisfatórios.

Pretende-se, finalmente, implementar mais elementos para atender a mais metadados de documentos PDF na medida em que sejam observadas as necessidades. Da mesma forma, após os testes realizados, os erros por parte do usuário que mais ocorreram deverão ser tratados no processo de extração, aumentando, dessa forma, o índice de sucesso de todo o processo.

Referências

Crescenzi, Y.; Mecca, G. Grammars have exceptions. Information Systems v. 23, n. 8, p.539-565., 1998.

Embley, D. W.; Tao, C.; Liddle, S. W. Automating the extraction of data from HTML tables with unknown structure. Data Knowledge Engineering. 54(1): 3-28 (2005). Laender, A. H. F., et al. The Debye Environment for Web Data Management. IEEE

Internet Computing. Volume 6, Issue 4 (July 2002). Pages: 60 – 69.

Laender, A. H. F.; Ribeiro-Neto, B.; Da Silva., A. S. DEByE - Data Extraction By Example, Data and Knowledge Engineering v. 40, n. 2, p. 121-154, 2002.

Manica, E.; Cervi, C.R.; Dorneles, C.F. Um Mecanismo Semi-automático de Auto-Arquivamento de Documentos em uma Biblioteca Digital. III Workshop on Digital Libraries (WDL 2007). Gramado, RS, 2007.

Mecca, G.; et al. The Araneus Web-Base Management System. In Proceedings of the ACM SIGMOD International Conference on Management of Data, p. 544-546, 1998. Silveira, I. C.; Heuser, C. A. Extração de Dados Semi-estruturados Através de

Exemplos e Ferramentas Visuais. In: CLEI, 2001, Mérida. p. 48-48.

Wessman, A.; Liddle, S. W.; Embley, D. W. A Generalized Framework for an Ontology-Based Data-Extraction System. ISTA 2005: 239-253.