Recuperação Contextualizada de Documentos Integrados pelo Protocolo OAI-PMH

Transcrição

1 UNIVERSIDADE FEDERAL DE GOIÁS INSTITUTO DE INFORMÁTICA RENAN RODRIGUES DE OLIVEIRA Recuperação Contextualizada de Documentos Integrados pelo Protocolo OAI-PMH Goiânia 2010

2 RENAN RODRIGUES DE OLIVEIRA Recuperação Contextualizada de Documentos Integrados pelo Protocolo OAI-PMH Dissertação apresentada ao Programa de Pós Graduação do Instituto de Informática da Universidade Federal de Goiás, como requisito parcial para obtenção do título de Mestre em Ciência da Computação. Área de concentração: Sistemas de Informação. Orientador: Prof. Dr. Cedric Luiz de Carvalho Goiânia 2010

3 RENAN RODRIGUES DE OLIVEIRA Recuperação Contextualizada de Documentos Integrados pelo Protocolo OAI-PMH Dissertação defendida no Programa de Pós Graduação do Instituto de Informática da Universidade Federal de Goiás como requisito parcial para obtenção do título de Mestre em Ciência da Computação, aprovada em 09 de Abril de 2010, pela Banca Examinadora constituída pelos professores: Prof. Dr. Cedric Luiz de Carvalho Instituto de Informática UFG Presidente da Banca Prof. Dr. João Carlos da Silva Instituto de Informática UFG Prof. Dr. Edleno Silva de Moura Instituto de Ciências Exatas Universidade Federal do Amazonas (UFAM)

4 Todos os direitos reservados. É proibida a reprodução total ou parcial do trabalho sem autorização da universidade, do autor e do orientador. Renan Rodrigues de Oliveira Graduou se em Ciência da Computação na PUC-Goiás (Pontifícia Universidade Católica de Goiás). Durante sua graduação, foi monitor de disciplinas e desenvolveu trabalhos de iniciação científica no Departamento de Computação da PUC-Goiás. Durante o mestrado na UFG (Universidade Federal de Goiás), foi bolsista da CAPES.

5 À Deus pela vida e oportunidades. Aos meus familiares e amigos.

6 Agradecimentos Agradeço a Deus, por tudo. Ao Prof. Dr. Cedric Luiz de Carvalho, pela orientação, dedicação e disponibilidade durante todo o período do mestrado. Aos Profs. Dr. João Carlos da Silva e Ms. Dirson Santos de Campos, por todas as sugestões que muito contribuíram para o desenvolvimento deste trabalho. Ao Prof. Ms. Júnio César de Lima, pelo apoio e incentivo. A todos os funcionários, amigos e demais professores do Instituto de Informática da Universidade Federal de Goiás. A CAPES, pelo suporte financeiro. Ao Prof. Dr. José Luiz de Freitas Júnior, pela orientação durante todo o período da minha graduação na PUC-Goiás, que me indicou por onde começar. A toda a minha família e amigos, pelo apoio recebido.

7 A coisa mais indispensável a um homem é reconhecer o uso que deve fazer do seu próprio conhecimento. Platão, Filósofo Grego.

8 Resumo de Oliveira, Renan Rodrigues. Recuperação Contextualizada de Documentos Integrados pelo Protocolo OAI-PMH. Goiânia, p. Dissertação de Mestrado. Instituto de Informática, Universidade Federal de Goiás. Este trabalho aborda duas vertentes: a integração de um conjunto de bibliotecas digitais, repositórios e outros provedores de dados por meio do protocolo OAI-PMH (Open Archives Initiative Protocol for Metadata Harvesting) e a recuperação contextualizada de documentos neste repositório integrado. Propõe-se a definição dos contextos utilizando ontologias e a análise do conteúdo de artigos de ambientes wiki. O interesse em ontologias está no seu uso como artefatos de especificação de domínios. Uma ontologia é um modelo de dados que representa um conjunto de conceitos e seus relacionamentos, dentro de um domínio de conhecimento. Um wiki é um ambiente colaborativo, que contêm uma coleção de artigos conectados através de hiperlinks, que podem ser editados coletivamente, através da utilização de um navegador web. Neste trabalho, os ambientes wiki são utilizados como um repositório de conhecimento auxiliar, para a extração de termos relevantes. Dessa forma, diversos conceitos e relacionamentos que podem não estar presentes na ontologia que especifica o domínio de conhecimento (uma vez que a construção de ontologias é um processo complexo) podem ser identificados. O resultado do processamento da ferramenta desenvolvida é um ranking de documentos ordenado por maior grau de relevância com relação à consulta fornecida por um usuário e a um determinado domínio de conhecimento, que é especificado por uma ontologia. Palavras chave OAI-PMH, Integração de Repositórios Digitais, Ontologias, Ambientes Wiki, Contextualização de Documentos

9 Abstract de Oliveira, Renan Rodrigues. Contextualized Retrieval of Documents Integrated by Protocol OAI-PMH. Goiânia, p. MSc. Dissertation. Instituto de Informática, Universidade Federal de Goiás. This work focuses on two aspects: the integration of a set of digital libraries, repositories and other data providers through the OAI-PMH protocol (Open Archives Initiative Protocol for Metadata Harvesting) and contextualized documents retrieval in this integrated repository. It is proposed the use of ontologies and content analysis of articles in wiki environments in the context definition. The interest in ontologies is in its use as artifacts of specification domain. An ontology is a data model that represents a set of concepts and their relationships within a domain of knowledge. A wiki is a collaborative environment, containing a collection of items connected by hyperlinks, which can be edited collectively by using a web browser. In this work, the wiki environments are used as an auxiliary repository of knowledge to the extraction of relevant terms. Thus, several concepts and relationships that may not be present in the ontology that specifies the domain of knowledge (since the construction of ontologies is a complex process) can be identified. The result of the developed tool processing is a ranking of documents ordered by a higher degree of importance with respect to the query provided by a user and a particular domain of knowledge, which is specified by an ontology. Keywords OAI-PMH, Integration of Digital Repositories, Ontologies, Wiki Environments, Contextualization of Documents

10 Sumário Lista de Figuras 12 Lista de Tabelas 14 1 Introdução Motivação Objetivos Trabalhos Relacionados Organização da Dissertação 20 2 Fundamentação Teórica Metadados O padrão Dublin Core 23 Elementos do Padrão Dublin Core Bibliotecas Digitais Integração e Interoperabilidade em Bibliotecas Digitais Ferramentas para a Implementação de Bibliotecas Digitais Ontologias Tipos de Ontologias Metodologias para a Construção de Ontologias Ferramentas para a Edição de Ontologias OWL (Web Ontology Language) Wikimedia MediaWiki 38 API do MediaWiki Recuperação de Informação Preparação dos Dados Textuais Modelos Clássicos para Recuperação de Informação 43 Modelo Booleano 43 Modelo Vetorial 44 Modelo Probabilístico Análise Semântica Latente Medidas de Avaliação 47 3 Open Archives Initiative Breve Histórico da Open Archives Initiative Principais Características da Open Arquives Initiative Arquitetura dos Open Archives Provedores de Dados 51

11 3.3.2 Harvesters Provedores de Serviços O protocolo OAI-PMH Esquema Básico do Protocolo OAI-PMH Verbos de Requisição do Protocolo OAI-PMH Identify ListMetadataFormats ListRecords ListIdentifiers GetRecord ListSets Ferramentas Implementadas pela Comunidade OAI Etapas para a Utilização do Protocolo OAI-PMH Seleção Ferramentas para os Harvester Coleta de Metadados Normalização dos Metadados 65 4 Desenvolvimento do Sistema Arquitetura do Sistema Integração de Provedores de Dados Recuperação de Documentos Analisador de Consulta Processador de Consulta 78 Construção da expressão booleana para a Recuperação de Documentos 78 Cálculo de Similaridade Implementação de Web Services ListarRepositorios ListarOntologias Buscar ObterRepositorio ObterOntologia ObterRegistro Implementação da Interface de Busca 87 5 Resultados Integração de Provedores de Dados Recuperação de Documentos Exemplos de Consultas e Análise de Resultados 99 6 Conclusões Contribuições Produção Bibliográfica Trabalhos Futuros 113 Referências Bibliográficas 114 A Respostas de Requisições do Protocolo OAI-PMH 128

12 B Respostas de Requisições do Web Service do Sistema Desenvolvido 134

13 Lista de Figuras 2.1 Tipos de ontologias, de acordo com o seu nível de generalidade Principais projetos desenvolvidos pela Wikimedia Parte da listagem do artigo Trânsito através da interface padrão da Wikipédia Trecho da resposta da requisição para a listagem do conteúdo do artigo Trânsito da Wikipédia, através da manipulação de sua API Arquitetura de um sistema de recuperação de informação Cosseno θ entre o documento d 1 e a consulta q (adaptado de [67]) Fluxo de informação nos provedores de dados Fluxo de informação nos provedores de serviços Esquema básico de funcionamento do protocolo OAI-PMH Arquitetura do sistema desenvolvido Processo adotado para a exposição de metadados de um diretório de dados não-estruturados Esquema geral utilizado no processo de integração de provedores de dados Algoritmo responsável pela coleta de metadados dos provedores de dados Modelo relacional utilizado no armazenamento dos metadados coletados Processo adotado para a recuperação contextualizada de documentos Trecho de uma ontologia desenvolvida para o domínio de Trânsito Anotação do conceito Automóvel, referente a uma ontologia do domínio de Trânsito Implementação de um ambiente wiki local, através da utilização do software MediaWiki Processo de seleção dos termos dos vetores de características Interface de busca para a recuperação de documentos do banco de dados integrado Interface responsável pela listagem do resultado de uma busca Interface responsável pela visualização de todos os itens de metadados de um determinado documento Interface responsável pela recuperação dos metadados de um documento através de seu código Interface responsável pela listagem de informações sobre todos os repositórios Interface responsável pela listagem de informações sobre todas as ontologias Diretório de dados não-estruturados 97

14 5.2 Exposição do conteúdo de um diretório de dados não-estruturados através do protocolo OAI-PMH Quantidade de documentos recuperados pela consulta Leis de Trânsito, considerando o domínio de conhecimento Trânsito Quantidade de documentos recuperados pela consulta Colisão de Trânsito, considerando o domínio de conhecimento Trânsito Quantidade de documentos recuperados pela consulta Colisão de Trânsito, considerando o domínio de conhecimento Sistemas Distribuídos (A) Trecho dos documentos monitorados do domínio de Trânsito (B) Trecho dos documentos monitorados do domínio de Sistemas Distribuídos Distribuição das posições de todos os documentos monitorados, para a consulta Colisão de Trânsito, considerando o domínio de conhecimento Trânsito Distribuição das posições de todos os documentos monitorados, para a consulta Colisão de Trânsito, considerando o domínio de conhecimento Sistemas Distribuídos 106 A.1 Trecho da resposta da Requisição 1, referente ao verbo Identify 128 A.2 Trecho da resposta da Requisição 2, referente ao verbo ListMetadataFormats 128 A.3 Trecho da resposta da Requisição 3, referente ao verbo ListMetadataFormats 129 A.4 Resposta da Requisição 4, referente ao verbo ListMetadataFormats 129 A.5 Trecho da resposta da Requisição 5, referente ao verbo ListRecords 129 A.6 Trecho da resposta da Requisição 6, referente ao verbo ListRecords 130 A.7 Trecho da resposta da Requisição 7, referente ao verbo ListRecords 130 A.8 Trecho da resposta da Requisição 8, referente ao verbo ListIdentifiers 131 A.9 Trecho da resposta da requisição 9, referente ao verbo ListIdentifiers 131 A.10 Trecho da resposta da requisição 10, referente ao verbo ListIdentifiers 131 A.11 Trecho da resposta da Requisição 11, referente ao verbo GetRecord 132 A.12 Resposta da Requisição 12, referente ao verbo GetRecord 132 A.13 Resposta da Requisição 13, referente ao verbo GetRecord 133 A.14 Trecho da resposta da Requisição 14, referente ao verbo ListSets 133 B.1 Trecho da resposta da Requisição 1, referente a ação ListarRepositorios 134 B.2 Trecho da resposta da Requisição 2, referente a ação ListarOntologias 135 B.3 Trecho da resposta da Requisição 3, referente a ação Buscar 135 B.4 Trecho da resposta da Requisição 1, referente a ação Buscar 136 B.5 Resposta da Requisição 5, referente a ação ObterRepositorio 136 B.6 Resposta da Requisição 6, referente a ação ObterOntologia 137 B.7 Resposta da Requisição 7, referente a ação ObterRegistro 137

15 Lista de Tabelas 2.1 URL API dos principais projetos da Wikimedia Requisição para a listagem do conteúdo do artigo Trânsito da Wikipédia Quantidade de metadados coletados da Biblioteca Digital de Teses e Dissertações da USP Quantidade de metadados coletados da Biblioteca Digital Jurídica do STJ Quantidade de metadados coletados do Repositório Digital da UFRGS Quantidade de metadados coletados da Biblioteca Digital de Teses e Dissertações da UFPR Quantidade de metadados coletados da Biblioteca Digital de Teses e Dissertações da UFRN Quantidade de metadados coletados do Repositório Ação Educativa Quantidade de metadados coletados da Biblioteca Virtual sobre Corrupção Quantidade de metadados coletados do Repositório Diálogo Científico Quantidade de metadados coletados do Repositório Institucional da UnB Quantidade de metadados coletados do Repositório local de dados nãoestruturados Exemplo de um vetor de termos referente a um documento Consulta sobre Leis de Trânsito, considerando o domínio de conhecimento Trânsito Consulta sobre Colisão de Trânsito, considerando o domínio de conhecimento Trânsito Consulta sobre Colisão de Trânsito, considerando o domínio de conhecimento Sistemas Distribuídos 103

16 Introdução CAPÍTULO 1 O surgimento da Internet proporcionou um grande avanço para a comunidade acadêmica. Por se tratar de uma rede de fácil acesso e de grande alcance geográfico, ela possibilitou o surgimento de novos recursos para a comunicação científica e o compartilhamento de conhecimento em todo o mundo. Estes novos recursos tornaram visível o contraste de tempo de produção e distribuição das publicações impressas e as publicações digitais [104]. Os recursos alternativos para comunicação científica proporcionados pela Internet otimizaram o processo de disseminação da informação e a criação de espaços virtuais para o compartilhamento do conhecimento científico [84]. O desenvolvimento dos mecanismos de publicação eletrônica para comunidade acadêmica, com o intuito de aumentar sua visibilidade, tornou-se uma questão essencial para o desenvolvimento e a ampliação das atividades de pesquisa científica. Através destes avanços tecnológicos que facilitam a publicação e difusão de informações, as bibliotecas digitais surgiram com o objetivo de dar acesso a toda informação digital armazenada em um determinado repositório de dados, tornando-se amplamente aceitas como fontes de divulgação de informação em diversas áreas do conhecimento. Elas permitem o acesso a documentos de alto valor cultural, histórico e social, bem como o seu armazenamento para construção da história e memória da humanidade. As bibliotecas digitais são um conjunto de recursos eletrônicos e capacidades técnicas associadas para criar, buscar e usar informações [150]. Nesse sentido, elas constituem uma extensão dos sistemas de armazenamento e recuperação de informação, que manipulam dados digitais nos mais variados formatos, operando em ambiente distribuído. As bibliotecas digitais prometem inúmeros e valiosos benefícios para a sociedade. O mais óbvio é o fim das restrições de espaço e tempo no acesso às informações. No entanto, as bibliotecas digitais logo se mostraram incapazes de satisfazer a totalidade das necessidades e demanda de informação dos usuários. Entre os vários motivos desta incapacidade, cita-se a dispersão das fontes, divergências nas interfaces de busca, falta de integração dos conteúdos, dentre outros [148]. A falta de padrões para disponibilização e pesquisa de informações científicas

17 1.1 Motivação 16 neste ambiente, levou à criação da Open Archives Initiative (OAI), que é uma iniciativa para desenvolver e promover padrões de interoperabilidade entre repositórios digitais. Uma das principais contribuições da OAI foi a criação do protocolo OAI-PMH (Open Archives Initiative Protocol for Metadata Harvesting), com o objetivo de facilitar a disseminação eficiente de conteúdo entre estes repositórios. A interoperabilidade entre repositórios digitais têm o objetivo de promover o acesso simultâneo aos dados contidos em diferentes repositórios e servidores na web, de forma a maximizar as buscas e reduzir o tempo de resposta. A integração consiste na disponibilização de serviços de recuperação de recursos informacionais heterogêneos e distribuídos, utilizando-se de uma interface única. Para os usuários, não interessa onde e nem como estes recursos estão armazenados [17]. O protocolo OAI-PMH vem se consolidando, como base para a interoperabilidade entre bibliotecas e repositórios digitais acadêmicos e científicos em todo o mundo. Através do OAI-PMH, é possível proporcionar visibilidade e integração de informações, com custos acessíveis à realidade de países em desenvolvimento, como o Brasil [105]. Entre os países que utilizam as tecnologias Open Archives, o Brasil se encontra em uma posição privilegiada. O Instituto Brasileiro de Informação em Ciência e Tecnologia (IBICT), atua como principal incentivador da adoção do modelo Open Archives pelas instituições brasileiras. 1.1 Motivação Devido à possibilidade de armazenamento e disponibilização de conteúdo de diversas áreas do conhecimento, as bibliotecas digitais abrangem uma grande variedade de assuntos e interesses. A maioria das interfaces de busca das bibliotecas digitais retornam uma grande quantidade de registros como ocorrências para o que foi pedido. O usuário nunca tem a certeza exata de que a informação desejada encontra-se entre as primeiras ocorrências retornadas. Dessa forma, cabe ao usuário analisar uma grande quantidade de registros para verificar quais deles realmente atendem às suas reais expectativas. De acordo com Lancaster [65], para qualquer necessidade específica de informação, haverá sempre muito mais itens que não possuem relevância ou pertinência com relação ao assunto pesquisado (itens inúteis) do que itens que possuam relevância ou pertinência com relação às necessidades desse usuário (itens úteis). Portanto, a principal função de um sistema de recuperação de informação é permitir que o usuário localize o maior número possível de itens relevantes [43]. Dessa forma, tornam-se aparentes as dificuldades de acesso e recuperação de informações relevantes. Assim, a busca de melhores métodos para armazenar, buscar e

18 1.1 Motivação 17 recuperar informações neste ambiente torna-se um desafio. Uma vez que a análise do contexto é indispensável para o bom entendimento dos termos utilizados nas buscas, mecanismos automáticos de contextualização podem possibilitar que apenas documentos relevantes sejam recuperados, de acordo como o interesse do usuário. Um dos principais problemas da contextualização automática de documentos está relacionado ao processo de definição formal dos contextos, ou seja, como criar contextos que permitam classificação automática de documentos. As ontologias possibilitam uma compreensão comum e compartilhada de um domínio, desempenhando um papel importante no intercâmbio de conhecimento, ao proporcionar uma estrutura semântica aos dados do domínio em questão. Uma ontologia é um modelo de dados que representa um conjunto de conceitos e seus relacionamentos, dentro de um domínio de conhecimento. Elas permitem que sistemas baseados em computador entendam o contexto que se encontra um determinado termo, permitindo um entendimento semântico com relação às situações do mundo real. No entanto, o processo de construção de uma ontologia é complexo, envolvendo o levantamento de conceitos relevantes e seus relacionamentos, com relação a um determinado domínio de conhecimento. De acordo com Maedche e Staab [1], a construção manual de ontologias é um processo oneroso, tedioso e propenso a erros. Dessa forma, importantes conceitos e relacionamentos com relação a um determinado domínio podem não estar mapeados na ontologia que especifica este domínio de conhecimento, devido à complexidade do seu processo de construção. Ao mesmo tempo, diversos ambientes wiki disponíveis na Internet contam com uma grande quantidade de artigos (páginas que contêm informações sobre um determinado assunto), cobrindo uma extensa faixa de temas e interesses. Por este motivo, estes ambientes têm sido utilizados por muitos pesquisadores em todo o mundo, como uma importante fonte para a extração de conhecimento. Um wiki (forma simplificada para WikiWikiWeb, derivada da expressão havaiana wiki wiki que significa rápido, ligeiro [110]) é um ambiente colaborativo, que contêm uma coleção de artigos conectados através de hiperlinks. Os ambientes wiki permitem que seus artigos sejam editados coletivamente por meio de uma linguagem de marcação muito simples e eficaz, através da utilização de um navegador web. Este cenário permite que os colaboradores dos ambientes wiki possam alterar e melhorar livremente o conteúdo dos artigos destes ambientes. A Wikipédia é o exemplo mais conhecido de wiki público [79]. Ela é uma enciclopédia online, desenvolvida por uma comunidade de usuários que cresce exponencialmente com a adição constante de conteúdo por seus colaboradores em todo planeta [149]. Em janeiro de 2010, a Wikipédia possuía mais de artigos em língua portuguesa.

19 1.2 Objetivos 18 O modelo de ambiente colaborativo, aliado à riqueza de conteúdo organizado hierarquicamente e interconectado que é presente nos ambientes wiki (como por exemplo a Wikipédia), têm motivado diversas pesquisas em todo o mundo na utilização destes ambientes como uma importante fonte de extração de conhecimento. 1.2 Objetivos Este trabalho aborda duas vertentes, que são os principais objetivos desta dissertação. São elas: a integração de um conjunto de bibliotecas digitais, repositórios e outros provedores de dados, integrados por meio do protocolo OAI-PMH; a recuperação contextualizada de documentos neste repositório integrado, de acordo com uma consulta fornecida por um usuário e um contexto especificado por uma ontologia. Neste trabalho, propõe-se a definição dos contextos utilizando ontologias e a análise do conteúdo de artigos de ambientes wiki no idioma Português. Estes ambientes wiki são utilizados como um repositório auxiliar para a extração de termos relevantes com relação à consulta e a um domínio de conhecimento. O resultado do processo de recuperação de informação é um ranking de documentos, ordenado por maior grau de relevância com relação à consulta e a um domínio de conhecimento especificado por uma ontologia. Dessa forma, estabelecendo-se um limiar com relação ao valor de similaridade que originou o ranking de documentos, obtém-se a separação entre os possíveis documentos relevantes, os documentos considerados de pouca relevância e os documentos irrelevantes. 1.3 Trabalhos Relacionados Nesta Seção, são apresentados alguns trabalhos relacionados a esta dissertação, com relação à utilização de tecnologias baseadas no modelo Open Archives, utilização de ontologias para a categorização e cálculo de similaridade semântica e a utilização de ambientes wiki como fonte de extração de conhecimento. Utilização de tecnologias do modelo Open Archives A Biblioteca Digital Brasileira de Teses e Dissertações (BDTD) [12] é um projeto coordenado pelo Instituto Brasileiro de Informação em Ciência e Tecnologia (IBICT) [53], que busca integrar em um só portal, os sistemas de informação

20 1.3 Trabalhos Relacionados 19 de teses e dissertações existentes no Brasil. O portal tem como proposta, além de disponibilizar gradativamente a produção nacional de teses e dissertações para consulta ou download, oferecer aos usuários produtos e serviços integrados capazes de proporcionar aumento significativo na qualidade do resultado de suas pesquisas. Suleman e Fox [52] apresentam uma visão geral da missão, filosofia e organização técnica da Open Archives Initiative. Cardoso Junior [69] apresenta o desenvolvimento de um sistema para o gerenciamento de bibliotecas digitais, denominado Clio-i. Neste sistema, é implementada uma extensão do protocolo OAI-PMH, sendo possível exportar metadados de documentos gerenciados localmente e realizar a coleta de metadados de qualquer provedor de dados em conformidade com o protocolo OAI-PMH. Utilização de ontologias para a categorização e cálculo de similaridade semântica Wu et al. [140] tratam da categorização de textos baseada em ontologias de domínio. Segundo os autores, a vantagem em se utilizar ontologias, comparada com outros mecanismos de representação do conhecimento é que a mesma pode ser lida, interpretada e editada por seres humanos. Erros podem ser detectados e com isso a descrição pode ser melhorada. Outra vantagem é a possibilidade do compartilhamento da ontologia por várias aplicações. Rigo et al. [134] propõe uma metodologia para a classificação de textos com uso de informações linguísticas descritas em uma ontologia de domínio. Esta ontologia possui as informações necessárias para identificação da estrutura e conceitos dos documentos associados a uma classe específica. Bloehdorn et al. [145] fazem uso das características conceituais extraídas de ontologias para melhorar a tarefa de classificação de textos. A abordagem é baseada na distribuição de hipóteses, ou seja, durante o processo de classificação, é verificado se os termos são semanticamente similares ao contexto ao qual eles estão compartilhados. Thiagarajan et al. [118] propõe um método para o cálculo de similaridade semântica com a utilização de uma ontologia. Neste processo, são adicionados termos que são próximos de um termo original na descrição de uma entidade, estendendo a noção de similaridade semântica, considerando as relações existentes entre seus conceitos. Utilização de ambientes wiki como fontes de extração de conhecimentos Gabrilovich e Markovitch [40] propõe um método que representa explicitamente o significado do conteúdo de qualquer texto, em um espaço de conceitos derivado da Wikipédia, utilizando técnicas de aprendizagem de máquina.

21 1.4 Organização da Dissertação 20 Nakayama, Hara e Nishio [64] propõe um método que analisa a estrutura de hiperlinks da Wikipédia para a construção de um Thesaurus. Segundo os autores, enquanto a maioria dos pesquisadores desta área analisam a estrutura de categorias da Wikipédia, neste trabalho propõe-se um método que analisa a estrutura de hiperlinks em torno dos artigos, uma vez que estes hiperlinks são relações explicitamente definidas pelos usuários. Nakayama et al. [63] apresentam características detalhadas da Wikipédia, que a torna uma importante fonte de extração de conhecimento. Neste trabalho, os autores descrevem alguns de seus experimentos, bem como pesquisas realizadas por outros pesquisadores, que demonstram a importância da Wikipédia como fonte de extração de conhecimento. Barth e Timoszczuk [41] propõe a utilização de um sistema de recuperação de informação que expande as consultas dos usuários de acordo com o conteúdo de uma lista de assuntos, que pode ser implementada como uma ontologia colaborativa, construída com a utilização de um ambiente wiki. Expansão de Consultas Qiu e Frei [172] apresentam um método de expansão de consultas que explora a correlação entre termos de uma coleção, onde os experimentos realizados mostram que a consulta expandida, no caso geral, produz resultados melhores que os obtidos através da consulta original. Ramalho e Robin [44] avaliaram os ganhos da precisão, cobertura e medida-f, obtidos a partir do uso de várias estratégias de expansão de consultas submetidas a um engenho de busca da web. Estas expansões foram realizadas de forma automática e baseadas em um Thesaurus: WordNet. Voorhees [35] fez uma avaliação sobre expansões de consultas utilizando sinônimos, medindo o impacto de usar-se conjuntamente a expansão de termos da consulta através de sinônimos e a eliminação de ambiguidade dos substantivos da consulta. 1.4 Organização da Dissertação Além deste Capítulo inicial que apresentou a introdução, motivação, objetivos e trabalhos relacionados, o restante do texto desta dissertação está organizado conforme descrito nos próximos parágrafos. No Capítulo 2, são apresentadas as fundamentações teóricas que são utilizadas para o desenvolvimento deste trabalho. Os principais assuntos discutidos são: metadados, bibliotecas digitais, ontologias, Wikimedia e recuperação de informação.

22 1.4 Organização da Dissertação 21 No Capítulo 3, apresenta-se a Open Archives Initiative (OAI), que desenvolve e promove padrões de interoperabilidade entre repositórios digitais, como um meio de aumentar a disponibilidade da comunicação científica. No Capítulo 4, apresentam-se as etapas implementadas para a construção do sistema desenvolvido nesta dissertação, com o propósito de possibilitar a recuperação contextualizada de documentos em um conjunto de bibliotecas digitais, repositórios e outros provedores de dados, integrados por meio do protocolo OAI-PMH. No Capítulo 5, apresentam-se os resultados obtidos pelo sistema desenvolvido, através da exposição de exemplos e análises de resultados, destacando a integração de provedores de dados e a recuperação contextualizada de documentos. No Capítulo 6, apresentam-se as conclusões finais, contribuições, produção bibliográfica e os trabalhos futuros. Após as referências bibliográficas, apresenta-se o Apêndice A, com as respostas em XML relativas às requisições do protocolo OAI-PMH que foram listadas na Seção 3.5 desta dissertação. Finalmente, no Apêndice B, são apresentadas as respostas em XML relativas aos exemplos de requisições ao web service do sistema desenvolvido, que foram listadas na Seção 4.4 desta dissertação.

23 Fundamentação Teórica CAPÍTULO 2 Este Capítulo apresenta as fundamentações teóricas que são utilizadas para o desenvolvimento deste trabalho. Na Seção 2.1 é apresentado o conceito de metadados, que refere-se a alguma estrutura descritiva de informação sobre outros dados. Na Seção 2.2 são apresentadas as bibliotecas digitais, que estão se tornando amplamente aceitas como fontes de divulgação de informação em diversas áreas do conhecimento. Na Seção 2.3 é apresentado o conceito de ontologia, que é um modelo de dados que representa um conjunto de conceitos e seus relacionamentos, dentro de um domínio de conhecimento. Na Seção 2.4 é apresentada a Wikimedia Foundation, uma organização dedicada ao incentivo, produção, desenvolvimento e distribuição de conteúdo livre e multilíngue para o acesso público. Finalmente, na Seção 2.5 é apresentado o conceito de recuperação de informação, que é uma tarefa que visa encontrar itens de informação relevantes para uma determinada necessidade de informação. 2.1 Metadados Os metadados são frequentemente chamados de dados sobre dados, no sentido de que referem-se a alguma estrutura descritiva de informação sobre outros dados. Para melhor compreender o conceito de metadados, é importante analisar algumas definições: A soma de tudo que pode ser dito sobre qualquer objeto de informação [156]. Dados que descrevem os atributos de um recurso, facilitando sua localização, descoberta, documentação, avaliação e seleção [128]. Máquina de informação compreensível sobre recursos da web ou outras coisas [154]. De um modo geral, os metadados têm a função de prover meios para: descoberta, disponibilidade, utilização, administração e controle de recursos [55]. Dessa forma,

24 2.1 Metadados 23 os metadados enriquecem ou complementam o potencial informativo dos objetos referenciados. A seguir, encontram-se algumas das diversas funções desempenhadas pelos metadados, as quais podem ser operacionalizadas por pessoas ou por agentes automatizados [38], [61], [77], [108]: disponibilizar a descrição de recursos de uma forma padronizada; fornecer um resumo do conteúdo de um determinado recurso de informação (isto é, do que trata o recurso), permitindo aos usuários determinar se este é exatamente o que eles desejam; dar condições aos usuários de procurar, recuperar e usar recursos de informação; quando formatos múltiplos são providos, ajuda os usuários na escolha de recursos de informação apropriados ao seu uso; prevenir usuários quanto às limitações no acesso aos dados, no que diz respeito a sistemas necessários, padrões e formatos adotados; instruir em como interpretar os dados (formato, codificação, criptografia, etc); fornecer informações que afetam o uso do recurso (por exemplo, condições legais de uso, idade mínima do usuário, cobrança de taxas, usos permitidos e não permitidos, etc); fornecer a história ou proveniência do recurso de informação, tal como sua fonte original e suas transformações subsequentes (filtragem, atualização, descarte, etc); fornecer especificações para o gerenciamento dos recursos de informação (data de última modificação, data de criação, identidade do administrador, etc); fornecer especificações sobre relações entre recursos (por exemplo, o relacionamento entre um conjunto de artigos e um jornal, entre um trabalho original e sua versão subsequente, entre componentes de um trabalho multimídia, etc); listar componentes lógicos de recursos de informação complexos e oferecer meios para acessar estes componentes (por exemplo, tabelas, lista de componentes de um software, etc). O amadurecendo da infra-estrutura da informação em sistemas computacionais e o aparecimento de novas comunidades e interesses, estão cada vez mais impulsionando o desenvolvimento de novos conjuntos de metadados, visando atender às atuais necessidades O padrão Dublin Core O Dublin Core é um padrão de metadados planejado para facilitar a descrição de recursos eletrônicos, estabelecidos através do consenso de grupos interdisciplinares

25 2.1 Metadados 24 internacionais de bibliotecários, cientistas da computação, comunidade de museus e outros estudiosos deste campo. O padrão Dublin Core possui dois níveis: Simples: Composto por quinze elementos, onde todos os elementos são opcionais e podem ser repetidos. Qualificado: É uma extensão do anterior, onde alguns dos seus elementos são acompanhados por um qualificador, que refinam a semântica dos elementos de maneira que sejam úteis na descoberta de recursos. O Dublin Core se caracteriza pela simplicidade, interoperabilidade, consenso internacional, extensibilidade e flexibilidade. A seguir, são destacados alguns destes princípios, adotados para a elaboração deste padrão [69], [32]: Simplicidade: O conjunto de elementos do Dublin Core foi estabelecido para ser simples e pequeno. Dessa forma, a maioria dos usuários (mesmo os não especialistas) podem descrever um recurso facilmente, permitindo assim, uma recuperação facilitada desses objetos eletrônicos por outros usuários. Semântica Universal: Devido às diferenças entre terminologias e descrições de recursos, a recuperação de informação no ambiente da Internet não é algo trivial. O Dublin Core foi criado para ajudar um pesquisador não especialista a achar um recurso através de elementos que são universalmente compreendidos. Por exemplo, se um repositório científico estiver estruturado de acordo com o padrão Dublin Core e houver a necessidade de encontrar um documento através de seu autor, basta procurar este documento pelo elemento creator. Esta representação mais genérica aumenta a visibilidade e acessibilidade ao recurso eletrônico. Extensibilidade: Para algumas aplicações, os conjuntos dos elementos Dublin Core não são suficientes para descrever um recurso. Dessa forma, espera-se que outras comunidades especializadas em metadados criem elementos adicionais para estes conjuntos. Tais elementos de refinamentos podem ser usados junto com os quinze elementos básicos do Dublin Core, para permitir uma melhor descrição e interoperabilidade. Elementos do Padrão Dublin Core A seguir, são apresentados os quinze elementos do Dublin Core [32]. Para cada elemento, são listados sua URI (Uniform Resource Identifier), o nome do rótulo (e a tradução para o idioma Português), sua definição (que indica a finalidade de uso) e exemplos ou comentários sobre estes elementos (com relação a sua finalidade de uso). 1. Contributor

26 2.1 Metadados 25 URI: Rótulo: Contributor (Contribuinte) Definição: Uma entidade responsável por contribuições intelectuais para o recurso de maneira secundária. Exemplos são: pessoas, organizações, serviços, etc. 2. Coverage URI: Rótulo: Coverage (Cobertura) Definição: A extensão ou cobertura espaço-temporal do recurso. Exemplos são: datas, intervalo de datas, localização, características de duração temporal do recurso, etc. 3. Creator URI: Rótulo: Creator (Criador) Definição: É a principal entidade responsável pela elaboração do conteúdo do recurso. Exemplos são: pessoas, organizações, serviços, etc. 4. Date URI: Rótulo: Date (Data) Definição: Um ponto ou período de tempo associado a um evento do ciclo de vida do recurso. Exemplos são: data de criação, data de modificação, etc. 5. Description URI: Rótulo: Description (Descrição) Definição: Uma descrição textual do conteúdo do recurso. Exemplos são: resumos (no caso do recurso ser um objeto com conteúdo textual), descrições do conteúdo do recurso (no caso do recurso ser um objeto visual), etc. 6. Format URI:

27 2.1 Metadados 26 Rótulo: Format (Formato) Definição: O formato do arquivo, meio físico ou as dimensões do recurso. Exemplos são: text/html, ASCII, PDF, JPG, etc. Exemplos de dimensões incluem tamanho e duração. 7. Identifier URI: Rótulo: Identifier (Identificador) Definição: Uma referência única (inequívoca), utilizada para identificar o recurso. Exemplos são: URL (Uniform Resource Locator), URN (Uniform Resource Name), URI (Uniform Resource Identifier), etc. 8. Language URI: Rótulo: Language (Idioma) Definição: O idioma do conteúdo do recurso. Exemplos são: pt (português), de (alemão), fr (francês), ja (japonês), etc. 9. Publisher URI: Rótulo: Publisher (Publicador) Definição: A entidade responsável por tornar o recurso disponível. Exemplos são: um editor, departamento universitário, uma entidade corporativa, etc. 10. Relation URI: Rótulo: Relation (Relação) Definição: Um recurso relacionado. Normalmente, são referências associadas a outros recursos que se relacionam com este recurso. 11. Rights URI: Rótulo: Rights (Direitos) Definição: Informações sobre direitos autorais do recurso.

28 2.2 Bibliotecas Digitais 27 Exemplos são: avisos ou declarações de direitos autorais, etc. 12. Source URI: Rótulo: Source (Fonte) Definição: Um recurso relacionado, a partir do qual o recurso descrito é derivado. Normalmente, são recursos relacionados no todo ou em parte. 13. Subject URI: Rótulo: Subject (Assunto) Definição: O tema do recurso. Exemplos são: palavras-chave, frases ou descritores de classificação, etc. 14. Title URI: Rótulo: Title (Título) Definição: Um nome dado ao recurso. Normalmente, são nomes pelo qual o recurso é formalmente conhecido. 15. Type URI: Rótulo: Type (Tipo) Definição: A natureza ou gênero do recurso. Exemplos são: romance, relatório técnico, ensaio, etc. O Dublin Core é um dos padrões de metadados mais utilizados, sendo o resultado de um esforço para se criar um padrão que servisse tanto a documentos quanto a objetos reais. Assim, ele têm sido adotado mundialmente e utilizado em vários projetos que buscam um entendimento entre diferentes comunidades de usuários. 2.2 Bibliotecas Digitais Com o aumento do uso da rede mundial de computadores e dos avanços tecnológicos que facilitam a publicação e difusão de informações, as bibliotecas digitais surgiram

29 2.2 Bibliotecas Digitais 28 com objetivo de possibilitar o acesso a toda informação digital armazenada em um determinado repositório de dados. Estes dados podem ser de diferentes tipos de objetos digitais (documentos, imagens, planilhas, vídeos, programas, etc.), devidamente catalogados por metadados, geralmente com interface de acesso web. O termo biblioteca digital, tema bastante discutido nas literaturas de Ciência da Informação e de Computação, pressupõe uma coleção de documentos disponíveis para os usuários em formato digital. O conceito de biblioteca digital aparenta algo revolucionário, mas na verdade ele é resultado de um processo gradual e evolutivo. Nas últimas décadas, o computador tem sido utilizado de forma cada vez mais crescente. Desde os anos 70, muitas bibliotecas implementaram mecanismos de automatização computacional de seus processos, passando a acessar bancos de dados para recuperar referências bibliográficas e textos completos de artigos, periódicos, verbetes de enciclopédias e itens de outras fontes de referência. A partir do fenomenal crescimento da Internet, as possibilidades de acessar e recuperar informações aumentaram de forma nunca antes imaginada [82]. Uma biblioteca tradicional é aquela onde a maioria dos itens do seu acervo é constituída de documentos em papel ou de outro artefato físico. Uma característica das bibliotecas tradicionais é que tanto a coleção como o seu catálogo utilizam o papel como suporte de registro da informação. As bibliotecas digitais ampliam os serviços das bibliotecas tradicionais, aproveitando as potencialidades do armazenamento e a comunicação digital para desenvolver serviços mais personalizados, promover acesso e utilização de informação multimídia, reduzir as barreiras de distância (sejam elas geográficas ou organizacionais) e o tempo no acesso à informação. Para a criação de uma biblioteca digital, é preciso que se estabeleça um repositório de publicações eletrônicas que armazene, preserve, divulgue e ofereça acesso à produção intelectual de uma instituição. Na literatura, pode-se encontrar diferentes definições de bibliotecas digitais. Entre elas, citam-se: São organizações que disponibilizam os recursos, incluindo pessoal especializado, para selecionar, estruturar, oferecer acesso intelectual, interpretar, distribuir, preservar a integridade e assegurar a persistência ao longo do tempo de coleções de trabalhos digitais, de forma que eles estejam prontamente e economicamente disponíveis para uso de uma comunidade definida ou um conjunto de comunidades [30]. Uma biblioteca que tem como base informacional conteúdos em texto completo em formatos digitais livros, periódicos, teses, imagens, vídeos e

30 2.2 Bibliotecas Digitais 29 outros que estão armazenados e disponíveis para acesso, segundo processos padronizados, em servidores próprios ou distribuídos e acessados via rede de computadores em outras bibliotecas ou redes de bibliotecas da mesma natureza [16]. Uma coleção organizada de dados multimídia com métodos de gerenciamento da informação, que representa os dados como informação útil e conhecimento para a sociedade, numa variedade de contextos sociais e organizacionais [146]. Uma biblioteca que contempla documentos gerados ou transpostos para o ambiente digital (eletrônico), um serviço de informação (em todo tipo de formato) no qual todos os recursos são disponíveis na forma de processamento eletrônico (aquisição, armazenagem, preservação, recuperação e acesso), através de tecnologias digitais [68]. Um conjunto de recursos eletrônicos e capacidades técnicas associadas para criar, buscar e utilizar informações [150]. Apesar do conceito de biblioteca digital não abordar o mesmo foco para diferentes comunidades de usuários, uma ou várias das seguintes características estão presentes em cada uma das diferentes definições encontradas na literatura [82]: acesso remoto pelo usuário, por meio de um computador conectado a uma rede de computadores; utilização simultânea do mesmo documento por duas ou mais pessoas; inclusão de produtos e serviços de uma biblioteca ou centro de informação; existência de coleções de documentos, onde se pode acessar não somente a referência bibliográfica, mas também o seu texto completo; possibilidade de acesso em rede a outras fontes externas de informação (bibliotecas, museus, bancos de dados, instituições públicas e privadas); disponibilização de documento de forma que a biblioteca local não necessite ser proprietária do documento solicitado pelo usuário; possibilidade de registro e manipulação de diversos tipos de informação tais como texto, som, imagem e vídeo; existência de uma unidade de gerenciamento do conhecimento, que inclui sistema inteligente ou especialista, para ajudar na recuperação de informações relevantes. Uma vez que são sistemas complexos, as bibliotecas digitais demandam grande esforço de desenvolvimento, sendo objetos de pesquisa multidisciplinar, construídas, adaptadas e testadas ao longo de vários anos de pesquisas.

31 2.2 Bibliotecas Digitais 30 Quando o potencial das bibliotecas digitais estiver consolidado, incluindo a presença de mecanismos de processamento semântico, haverá a possibilidade de acesso imediato a qualquer conhecimento humano documentado, a partir de qualquer lugar e de forma mais precisa. A facilidade com que uma biblioteca digital pode fazer trafegar um documento de um local para outro leva a concluir que as ações cooperativas com entidades afins venham a ser estimuladas. O computador que hospeda o acervo de uma determinada biblioteca digital (servidor) pode estar a milhares de quilômetros do computador do usuário (cliente), que faz requisições a documentos digitais remotos. Para os usuários, o que importa é que o documento completo seja acessível de forma rápida, econômica e sem dificuldades de outra natureza [83] Integração e Interoperabilidade em Bibliotecas Digitais As bibliotecas digitais são desenvolvidas com diferentes arquiteturas e tecnologias, são gerenciadas por organizações distintas, submetidas a diferentes padrões de qualidade, etc. Este ambiente distribuído e heterogêneo introduz um alto grau de complexidade na conquista de uma visão integrada das coleções digitais [135]. A ideia geral de integração e interoperabilidade em bibliotecas digitais consiste na disponibilização de serviços de recuperação de recursos informacionais heterogêneos, armazenados em diferentes repositórios e servidores na web, utilizando-se de uma interface única. Dessa forma, integração é a capacidade de disponibilização de uma interface única para acesso às informações disponíveis em diferentes bibliotecas digitais. Para os usuários, não interessa onde e nem como estes recursos estão armazenados. A interoperabilidade é a capacidade das bibliotecas digitais trocarem e compartilharem informações e serviços. No cenário mundial, identificam-se várias alternativas de interoperabilidade e acesso integrado a recursos informacionais distribuídos e heterogêneos, que podem ser agrupadas de acordo com o tipo de interoperabilidade adotado. Basicamente, são duas alternativas, embora ainda não se tenha fixado uma nomenclatura consensual [17]: Busca Distribuída: A busca é distribuída a diferentes repositórios identificados como capazes de fornecer respostas satisfatórias, onde os resultados são integrados. Base de Metadados Centralizada: Metadados referentes a documentos armazenados em diferentes repositórios são coletados periodicamente, alimentando uma base comum de metadados, sobre a qual são realizadas as buscas. Com a finalidade de permitir a integração e interoperabilidade neste ambiente, diversos protocolos foram desenvolvidos. Entre eles, podem ser citados:

32 2.2 Bibliotecas Digitais 31 Z39.50 [3]: É um protocolo de comunicação que permite pesquisas e recuperação de informações em redes de computadores distribuídos. É baseado na arquitetura cliente/servidor, operando na Internet. SDLIP [137]: É um protocolo desenvolvido em colaboração com universidades e outros projetos de pesquisas norte-americanas, para a integração de fontes de informação heterogêneas. O SDLIP (Simple Digital Library Interoperability Protocol) permite uma opção de implementação baseada em CORBA e outra através de requisições HTTP [26]. Dienst [29]: É um protocolo implementado em HTTP, que permite a comunicação entre servidores de bibliotecas digitais geograficamente distribuídas, possibilitando o acesso de suas coleções de documentos. SRU/SRW [142] [143]: O protocolo SRU (Search and Retrieve URL) e o SRW (Search and Retrieve Web Service) foram concebidos pelo mesmo grupo que criou o protocolo Z O protocolo SRU tem como objetivo facilitar a codificação de comandos do cliente para o servidor em uma string na forma de um URL, onde a especificação dos valores transmitidos é realizado com a passagem de parâmetros neste mesmo URL. O SRW se diferencia do SRU pelo uso do serviço SOAP (Simple Object Access Protocol), que é pré-estabelecido. O SOAP encapsula e transporta as chamadas de procedimentos remotos, criando mensagens estruturadas no formato XML para a troca de informação em ambientes distribuídos. OAI-PMH [93]: É um protocolo que permite a disseminação eficiente de conteúdo entre repositórios digitais. O OAI-PMH (Open Archives Initiative Protocol for Metadata Harvesting) possibilita aos participantes da iniciativa OAI (Open Archives Initiative) compartilhar seus metadados, para aplicações externas que se interessem na coleta desses dados. Este protocolo fornece uma interface bastante simples, baseada em HTTP e XML. Os metadados coletados podem estar em qualquer formato previamente definido por uma comunidade, embora o padrão Dublin Core seja especificado para fornecer um nível básico de interoperabilidade. Entre os motivos que tornam o protocolo OAI-PMH como um dos principais protocolos para interoperabilidade em bibliotecas digitais, destaca-se a sua simplicidade de implementação, arquitetura de baixo custo e a existência de ferramentas open source para a implementação de repositórios digitais (conforme apresentado nas Seções e 3.6) que também implementam este protocolo Ferramentas para a Implementação de Bibliotecas Digitais Uma biblioteca digital é muito mais do que uma coleção de textos e outros objetos digitalizados. As ferramentas tecnológicas para a construção desses novos modelos

33 2.2 Bibliotecas Digitais 32 de divulgação de informação estão sendo continuamente implementados e colocados a disposição das comunidades de desenvolvedores e usuários. Em sua maioria, as ferramentas para criação de bibliotecas digitais são sistemas livres, com código aberto, geralmente desenvolvidos por universidades e disponibilizados gratuitamente, sendo alternativa para que qualquer organização implemente seu acervo digital. Dessa forma, estas ferramentas podem ser livremente instaladas, testadas, usadas e personalizadas pelos interessados neste tipo de aplicação. De alguma forma, estas ferramentas procuram cobrir as diferentes necessidades dos usuários [27]. No restante desta seção, são apresentadas algumas ferramentas para implementação de bibliotecas digitais [99]. Archimèd [8]: O Archimèd foi desenvolvido pela Laval University Library na cidade de Quebec no Canadá. O projeto desta ferramenta foi modelado para permitir o depósito de pre-prints (primeira versão de um documento publicado) e post-prints (versão final de um documento após revisões do autor) de universidades e pesquisadores. ARNO [9]: O projeto ARNO (Academic Research in the Netherlands Online), foi desenvolvido para dar suporte à implementação de repositórios institucionais e integrar repositórios distribuídos por todo o mundo. Entre os participantes do projeto estão a University of Amsterdam, Tilburg University e a University of Twente. CDSware [18]: O CDSware (CERN Document Server Software), foi desenvolvido e está sendo mantido disponível publicamente pelo CERN (European Organization for Nuclear Research). O CERN utiliza o CDSware para gerenciar cerca de 350 coleções de dados, englobando cerca de registros bibliográficos e documentos completos, incluindo pre-prints, jornais, artigos, livros e fotografias. DSpace [31]: O DSpace é um software livre desenvolvido pelo MIT (Massachusetts Institute of Technology) e pelos Laboratórios Hewlett-Packard para criação de repositórios institucionais e multidisciplinares para bibliotecas, arquivos e centros de pesquisa. Sua estrutura oferece um modelo de informação organizacional baseado em comunidades e coleções, o qual pode ser configurado de modo a refletir todo o conjunto das unidades administrativas de uma instituição. Permite os mais variados tipos de formatos de arquivos digitais, incluindo textos, sons e imagens. EPrints [37]: O EPrints foi desenvolvido pela University of Southampton, tendo se mostrado apropriado para a construção de repositórios institucionais. É uma ferramenta aberta, relativamente fácil de instalar e adaptável às necessidades de qualquer instituição de ensino e pesquisa.

34 2.2 Bibliotecas Digitais 33 Fedora [42]: O Fedora (Flexible Extensible Digital Object and Repository Architecture) é uma plataforma de código aberto, desenvolvido pela University of Virginia e pela Cornell University, que oferece uma arquitetura projetada para servir como base para a implementação de repositórios digitais para uma grande variedade de aplicações, tais como bibliotecas digitais, repositórios institucionais e outros sistemas gerenciadores de informação. O núcleo central do Fedora é o repositório de serviços, que pode ser acessado utilizando interfaces via web service, que permite a criação, gerenciamento, armazenamento, acesso e o reuso dos objetos digitais. Todas as funções do Fedora, tanto no nível de administração do repositório como no nível do acesso aos objetos digitais, são disponibilizados por meio deste repositório de serviços. Em 2005, foi integrado o primeiro estágio para a tecnologia da Web Semântica no repositório de serviços do Fedora, introduzindo suporte para descrições RDF (Resource Description Framework) de objetos digitais, relacionamentos RDF e indexação do repositório baseada em grafos. Com esta implementação, os objetos do repositório podem ser tratados como nós de um grafo, permitindo que se façam consultas neste grafo. O impacto desta adaptação foi significante, uma vez que posiciona o Fedora como o único sistema de código aberto que combina redes de informações semânticas do conteúdo com suporte a persistência e gestão do conteúdo digital. Greenstone [48]: O Greenstone é uma ferramenta para o desenvolvimento e distribuição de coleções de bibliotecas digitais. Esta ferramenta foi desenvolvida através do projeto da New Zealand Digital Library Project e University of Waikato, e distribuído em cooperação com a UNESCO e o projeto Human Info NGO. i-tor [54]: O i-tor (Tools and technologies for Open Repositories) foi desenvolvido pelo ITA (Innovative Technology Applied), uma seção do Instituto para Serviços de Informação Científica da Holanda. Através de uma interface web, esta ferramenta permite que seus usuários apresentem vários tipos de informações, independente do local onde os dados são armazenados ou o formato em que são apresentados. MyCoRe [85]: O MyCoRe é um software de código aberto, utilizado para que instituições possam construir seus próprios repositórios digitais. O MyCoRe atualmente está sendo desenvolvido por um consórcio de universidades para prover uma ferramenta para dar suporte a bibliotecas digitais ou repositórios de conteúdo (Content Repositories, daí o nome CoRe ). O software foi projetado para ser configurado e adaptado às exigências locais de cada instituição (daí o nome My ), sem a necessidade de esforços de programação. OPUS [100]: O OPUS (Online Publications of the University of Stuttgart) foi desenvolvido pela University Library e o Computing Center of the University of

35 2.3 Ontologias 34 Stuttgart. O objetivo do projeto original foi oferecer um sistema onde estudantes e universidades pudessem gerenciar todas as suas publicações eletrônicas. 2.3 Ontologias O termo ontologia tem origem na filosofia grega 1. Na filosofia, uma ontologia é uma teoria sobre a existência da natureza, sobre os tipos de coisas que existem ou o que se dizer sobre o mundo [59]. Quando relacionado à Ciência da Computação, o termo ontologia tem seu sentido diferente daquele tradicionalmente adotado na filosofia. Neste caso, uma ontologia é um modelo de dados que representa um conjunto de conceitos e seus relacionamentos dentro de um domínio de conhecimento. Uma das definições mais citadas na literatura é a de Gruber [152], que define ontologia como: Uma ontologia é uma especificação formal, explícita e compartilhada de uma conceituralização. Posteriormente Studer, Benjamins e Fensel [129] analisaram cada um dos termos desta definição: conceitualização: refere-se a um modelo abstrato de algum fenômeno no mundo, pela identificação de conceitos relevantes desse fenômeno; explícita: significa que o tipo de conceito usado e suas restrições estão explicitamente definidos; formal: refere-se ao fato de que a ontologia pode ser compreendida pelas máquinas; compartilhada: refere-se à noção de que uma ontologia captura um conhecimento aceito por um grupo de pessoas e não o conhecimento particular de um indivíduo. De uma maneira geral, as ontologias são especialmente úteis na gerência do conhecimento para recuperação da informação, pois unifica termos, conceitos, categorias e relações de um mesmo domínio, permitindo o reuso Tipos de Ontologias De acordo com Guarino [89] [90] [91], com relação ao seu nível de generalidade, as ontologias podem ser classificadas nas seguintes categorias: 1 Aristóteles a.c.

36 2.3 Ontologias 35 Ontologias Genéricas: descrevem conceitos bastante gerais, independentes de um problema ou domínio particular, tais como, espaço, tempo, matéria, objeto, evento, ação, etc. Ontologias de Domínio: descrevem conceituações de domínios particulares, com relação ao vocabulário relacionado a um domínio genérico, tais como medicina ou automóveis. Ontologias de Tarefa: descrevem o vocabulário relacionado a uma atividade ou tarefa genérica, independente do domínio em que ocorrem, tais como diagnóstico ou vendas. Ontologias de Aplicação: descrevem conceitos dependentes do domínio e da tarefa particular. Estes conceitos frequentemente correspondem a papéis desempenhados por entidades do domínio quando da realização de uma certa atividade. A Figura 2.1 mostra o relacionamento entre estas categorias para a classificação de ontologias, de acordo com o seu nível de generalidade. Figura 2.1: Tipos de ontologias, de acordo com o seu nível de generalidade Conforme pode ser observado na Figura 2.1, os conceitos de uma ontologia de domínio ou de tarefa devem ser especializações dos termos introduzidos por uma ontologia genérica. Os conceitos de uma ontologia de aplicação, por sua vez, devem ser especializações dos termos das ontologias de domínio e de tarefa correspondentes Metodologias para a Construção de Ontologias Na literatura, existem várias metodologias, ferramentas e linguagens que podem ser utilizadas para construção de uma ontologia. Não existe só um método, ferramenta ou linguagem correta, ou seja, existem vários caminhos que podem ser seguidos para chegar ao objetivo. A escolha correta é aquela que contempla todas as necessidades para a construção da ontologia em particular [59].

37 2.3 Ontologias 36 As principais metodologias para a construção de ontologias são: Cyc [147], Grüninger e Fox [76], Uschold e King [80], Kactus [2], Methontology [72], Sensus [14], Ontology Development 101 [87] e On-To-Knowledge [144]. Existem outras metodologias além das já citadas. Mais informações sobre estas metodologias podem ser encontradas em [60], [25], [73], [81] e [174] Ferramentas para a Edição de Ontologias As ferramentas para a edição de ontologias constituem-se em importantes mecanismos para o processo de construção e manutenção de ontologias. Na maioria dos casos, estas ferramentas fornecem ambientes interativos e com boa usabilidade com relação à interface disponibilizada aos usuários. Uma vez que a construção de ontologias é algo complexo e dispendioso, qualquer apoio neste processo pode representar ganhos significativos, principalmente com relação ao tempo de desenvolvimento e a qualidade final da ontologia. As principais ferramentas para a edição de ontologias são: Protégé [88], OilEd [138], OntoEdit [173], Ontolingua [151], WebOnto [58] e WebODE [101]. Existem outras ferramentas além das citadas no parágrafo anterior. Mais informações sobre estas ferramentas podem ser encontradas em [11], [60], [96], [74], [117] OWL (Web Ontology Language) As linguagens para representação de ontologias variam de acordo com o seu poder de formalismo e expressividade. Dentre elas, pode-se citar: SHOE (Simple HTML Ontology Extensions) [141], XOL (Ontology Exchange Language) [170], DAML (DARPA Agent Markup Language) [23] e OIL (Ontology Inference Layer) [95]. As duas últimas foram combinadas e formaram a DAML+OIL [24]. A OWL (Web Ontology Language) [28], [102], [139] é uma revisão da linguagem DAML+OIL. Desde 10 de fevereiro de 2004, esta é a linguagem recomendada pelo W3C (World Wide Web Consortium) [157] para a representação de ontologias. Em termos de sua expressividade para a representação de conteúdo semântico interpretável por máquinas, a OWL pode ser considerada como uma evolução das demais linguagens para representação de ontologias. De acordo com o W3C, a linguagem OWL é projetada para ser utilizada pelas aplicações que necessitam processar o conteúdo das informações, ao invés de apenas apresentar estas informações aos seres humanos. Esta linguagem possui três classes de sub-linguagens, projetadas para serem utilizadas por diferentes comunidades de implementadores e usuários. São elas [102]:

38 2.4 Wikimedia 37 OWL-Lite: é a sub-linguagem sintaticamente mais simples. Destina-se a situações em que apenas são necessárias uma classificação hierárquica e restrições simples. OWL-DL: é mais expressiva que a OWL-Lite e baseia-se em lógica descritiva (DL Description Logics), que é uma área de pesquisa que estuda um fragmento particular da lógica de primeira ordem, e portanto, é passível de raciocínio automático. Destina-se a situações em que é necessário o máximo de expressividade, com completude (todas as conclusões são computáveis) e decidibilidade (todas as computações terminarão em um tempo finito). OWL-Full: é a sub-linguagem mais expressiva. Destina-se a situações onde a alta expressividade é mais importante do que qualquer garantia computacional. Esta alta expressividade pode introduzir dificuldades com relação ao processamento semântico. Cada uma destas sub-linguagens é uma extensão de sua predecessora, ou seja, cada ontologia válida em OWL-Lite é uma ontologia válida em OWL-DL, esta por sua vez é uma ontologia válida em OWL-Full [103]. 2.4 Wikimedia A Wikimedia Foundation [159] é uma organização dedicada ao incentivo, produção, desenvolvimento e distribuição de conteúdo livre e multilíngue para o acesso público. Os maiores projetos de referência editados colaborativamente em todo o mundo são operados pela Wikimedia, incluindo a Wikipédia que é um dos sites mais visitados da Internet. Os principais projetos da Wikimedia são desenvolvidos colaborativamente através do software MediaWiki. Na Figura 2.2, apresenta-se a logomarca dos principais projetos desenvolvidos pela Wikimedia. Figura 2.2: Principais projetos desenvolvidos pela Wikimedia

39 2.4 Wikimedia 38 A seguir, são apresentadas breves descrições dos principais projetos desenvolvidos pela Wikimedia: MediaWiki [75]: é o software utilizado pelos principais projetos da Wikimedia. Este software é apresentado na seção Wikipédia [162]: é o exemplo mais conhecido de wiki público [79], destinado a construir enciclopédias livres em todos os idiomas do mundo. Ela têm sido desenvolvida por uma comunidade de usuários, que cresce exponencialmente com a adição constante de conteúdo por seus colaboradores em todo planeta [149]. Em janeiro de 2010, a Wikipédia possuía mais de artigos em língua portuguesa. Wiktionary [167]: é um projeto para a criação de um dicionário multilíngue de conteúdo livre. Sua proposta é ser muito mais abrangente que um dicionário comum, incluindo thesaurus, rimas, traduções, pronúncias em áudios e citações. Wikiquote [163]: é um repositório de citações de pessoas famosas, livros, discursos, filmes ou qualquer outro material intelectualmente interessante. Wikibooks [158]: é uma coleção de fontes de e-books livres, incluindo livros didáticos, cursos de línguas, manuais e livros de domínio público. Wikisource [164]: é uma coleção de textos que podem ser distribuídos de forma livre e aberta. Wikispecies [165]: é um projeto que provê uma base de dados de espécies para taxonomia. Wikinews [161]: é um repositório de notícias sobre uma grande variedade de assuntos, onde pessoas de todo o mundo escrevem reportagens colaborativamente. As notícias englobam desde reportagens e entrevistas originais até resumos de artigos de fontes externas. Wikiversity [166]: é um projeto dedicado a comunidades estudantis e conteúdos didáticos, em todos os níveis de escolaridade. Wikimedia Commons [160]: é um repositório central para fotos, diagramas, mapas, vídeos, animações, músicas, sons, textos e outras mídias gratuitas. É um projeto multilíngue que serve como repositório central para todos os projetos da Wikimedia MediaWiki O MediaWiki é o software utilizado por grande parte dos projetos da Wikimedia. O MediaWiki é um pacote de software livre extremamente poderoso, escalável e com uma rica implementação para o desenvolvimento de ambientes colaborativos. O MediaWiki foi originalmente escrito para a Wikipédia e tem sido utilizado por diversas organizações em todo o mundo.

40 2.4 Wikimedia 39 API do MediaWiki A API do software MediaWiki disponibiliza uma grande quantidade de serviços, que podem ser facilmente acessados. Estes serviços possibilitam a recuperação de informações úteis com relação a todo o conteúdo disponibilizado por este software. Na Tabela 2.1, apresenta-se o URL API (uma string para requisições) dos principais projetos desenvolvidos pela Wikimedia. Projeto URL API Wikipédia Wiktionary Wikiquote Wikibooks Wikisource Wikispecies Wikinews Wikiversity Wikimedia Commons Tabela 2.1: URL API dos principais projetos da Wikimedia A seguir, apresentam-se alguns exemplos da manipulação da API do software MediaWiki, onde {api} refere-se a URL API de qualquer projeto que utilize este software, {artigo} e {categoria} referem-se, respectivamente, a qualquer artigo e categoria do projeto referenciado por {api}. São eles: Listagem das superclasses com relacionamento direto com {artigo}: {api}?action=query&prop=categories&titles={artigo} Listagem das superclasses com relacionamento direto com {categoria}: {api}?action=query&prop=categories&titles=categoria:{categoria} Listagem dos membros (artigos e subclasses) de {categoria}: {api}?action=query&list=categorymembers& cmtitle=category:{categoria} Listagem do conteúdo do {artigo}: {api}?action=query&prop=revisions&titles={artigo}& rvprop=timestamp content Listagem da URL de todas as imagens de {artigo}: {api}?action=query&prop=images&titles={artigo} Listagem de todos os artigos que possuem link para {artigo}: {artigo}?action=query&generator=backlinks&gbltitle={artigo}& prop=info Listagem de todos os links de {artigo}: {api}?action=query&prop=links&titles={artigo}

41 2.4 Wikimedia 40 Listagem de todos os links externos do artigo {artigo}: {api}?action=query&prop=extlinks&titles={artigo} Busca de artigos pelo conjunto de termos {artigo}: {api}?action=query&list=search&srsearch={artigo} A Tabela 2.2 apresenta um exemplo da manipulação da API da Wikipédia, através de uma requisição para a recuperação do conteúdo do artigo Trânsito. Exemplo da manipulação da API da Wikipédia prop=revisions&titles=trânsito&rvprop=content Tabela 2.2: Requisição para a listagem do conteúdo do artigo Trânsito da Wikipédia Na Figura 2.3, para propósitos de comparação da resposta da requisição da Tabela 2.2, apresenta-se parte da listagem do artigo Trânsito através da interface padrão da Wikipédia. Na Figura 2.4, apresenta-se um trecho da resposta da requisição para a listagem do conteúdo do artigo Trânsito da Wikipédia, através da manipulação de sua API. Figura 2.3: Parte da listagem do artigo Trânsito através da interface padrão da Wikipédia

42 2.5 Recuperação de Informação 41 Figura 2.4: Trecho da resposta da requisição para a listagem do conteúdo do artigo Trânsito da Wikipédia, através da manipulação de sua API 2.5 Recuperação de Informação A recuperação de informação é uma área da Computação que trabalha na tarefa de encontrar itens de informações relevantes para uma determinada necessidade de informação, que é expressa por uma requisição de um usuário (consulta), disponibilizando-a de uma forma adequada ao propósito da busca por ele submetida [127]. O problema central na recuperação de informação é encontrar documentos com informações que realmente são de interesse de um determinado usuário. A principal ferramenta usada para resolver este problema é o emprego de sistemas de recuperação de informação. O usuário de um sistema de recuperação de informação geralmente traduz a sua necessidade de informação mediante a especificação de uma consulta que, na maioria dos casos, é um conjunto de palavras-chave que são usadas para recuperar os documentos de uma coleção. Na Figura 2.5, apresenta-se a arquitetura de um sistema de recuperação de informação.

43 2.5 Recuperação de Informação 42 Figura 2.5: Arquitetura de um sistema de recuperação de informação De uma forma geral, conforme apresentado na Figura 2.5, um sistema de recuperação de informação realiza as seguintes tarefas em resposta a uma consulta do usuário [70]: Processo de Indexação: são geradas estruturas de dados associados à parte textual dos documentos. Normalmente, cada documento é descrito através de um conjunto de termos que, em teoria, representam melhor o seu conteúdo. Processo de Definição da Consulta: envolve a especificação da necessidade do usuário, normalmente definida por um conjunto de termos. O sistema deve analisar a consulta e transformá-la em uma estrutura que melhor possibilite a recuperação de itens considerados relevantes. Processo de Recuperação: consiste na construção da lista de documentos considerados relevantes, baseado no cálculo do grau de similaridade entre o conteúdo dos documentos da coleção (armazenados no índice) e os termos da consulta. Normalmente, o resultado de um sistema de recuperação de informação é apresentado através de um ranking de documentos (lista ordenada), de acordo com o grau de relevância dos documentos com relação à consulta do usuário. O grau de relevância de cada documento está relacionado ao julgamento com relação aos documentos que melhor expressam a informação desejada. A relevância de um documento indica a importância do mesmo para uma consulta, sendo o principal componente para determinar o ranking de documentos [66].

44 2.5 Recuperação de Informação Preparação dos Dados Textuais A preparação dos dados textuais consiste em uma sequência de atividades, com o objetivo de selecionar o que melhor expressa o conteúdo dos documentos. Este processo reduz a dimensionalidade das informações textuais e contribui para a redução do esforço computacional referente ao processo posterior de recuperação de informação. A seguir, são apresentadas as principais atividades realizadas na preparação dos dados textuais: Tokenização: consiste na subdivisão do documento textual em um conjunto de palavras (denominados tokens), convertidos para um mesmo tipo de letra (maiúsculo ou minúsculo), através da identificação de caracteres delimitadores. Neste processo, é comum a eliminação de dígitos numéricos, hífens, sinais de pontuação, acentos ou qualquer outro caractere especial que não contribuia para a representatividade do documento textual. Remoção de Stopwords: consiste na remoção de palavras consideradas irrelevantes (stopwords) para a representatividade dos documentos, tais como artigos, pronomes, interjeições, advérbios, preposições, etc. Essas palavras são eliminadas, uma vez que normalmente não traduzem a essência do documento textual, possuindo um baixo valor semântico. Normalização Morfológica (Stemming): consiste na redução de termos a um radical comum, através da eliminação de suas diferenças morfológicas ou lexicais Modelos Clássicos para Recuperação de Informação Os modelos clássicos para recuperação de informação (booleano, vetorial e probabilístico) apresentam estratégias de busca de documentos relevantes para uma consulta. Tanto a consulta feita pelo usuário, quanto os documentos que compõem a coleção a ser pesquisada são representados pelos seus termos. Modelo Booleano O modelo booleano é baseado na teoria dos conjuntos e na álgebra booleana, onde os documentos são representados por um conjunto de termos indexados. Os documentos recuperados são aqueles que contêm os termos que satisfazem a expressão lógica da consulta. Uma consulta é considerada como uma expressão booleana convencional formada com os conectivos lógicos AND, OR e NOT.

45 2.5 Recuperação de Informação 44 Modelo Vetorial No modelo vetorial, tanto os documentos quanto as consultas são representadas como vetores de termos no espaço euclidiano R T, onde T é a quantidade de termos que constitui os vetores. Para cada termo, existe um valor associado que indica o peso (grau de relevância) do termo no vetor que representa o documento ou a consulta. O peso do termo t i no documento d j, denominado w i j, é frequentemente calculado como se segue [47]: w i j = f i j log N n i (2-1) onde f i j é a frequência do termo i no documento d j, N é o número de documentos da coleção e n i é o número de documentos em que o termo i ocorre. O valor w i j também é conhecido como TF-IDF. O fator log N n i é denominado IDF (Inverse Document Frequency). O valor f i j, também conhecido como TF (Term Frequence), é uma medida da importância do termo i no documento, ou seja, quanto mais frequente é um termo, mais importante ele é para o documento. O fator IDF é uma medida da importância do termo i na coleção, ou seja, quanto menos frequente é um termo, mais importante ele é na coleção [71]. A similaridade entre uma consulta q e um documento d pode ser calculada através do cosseno do ângulo formado pelos vetores de termos q e d, utilizando a seguinte expressão [111]: do vetor q. sim(d,q) = t i=1 t i=1 w id w iq (2-2) t (w id ) 2 (w iq ) 2 onde w id é o peso do i-ésimo termo do vetor d e w iq é o peso do i-ésimo termo Na Figura 2.6, é ilustrada a medida do cosseno do ângulo θ entre o documento d 1 e a consulta q, onde: v(d i ) representa o documento d i no espaço euclidiano R 2 ; i=1 v(q) representa a consulta no espaço euclidiano R 2.

46 2.5 Recuperação de Informação 45 Figura 2.6: Cosseno θ entre o documento d 1 e a consulta q (adaptado de [67]) Ao calcular o cosseno do ângulo θ entre um documento e a consulta, quanto mais próximo de 1 for o resultado, maior é a similaridade entre este documento com relação à consulta. Modelo Probabilístico O modelo probabilístico trabalha com conceitos provenientes da área de probabilidade e estatística. A base deste modelo está no princípio da ordenação probabilística (Probability Ranking Principle): dada uma consulta q e um documento d j de uma coleção, tenta-se estimar a probabilidade do usuário considerar o documento d j relevante à consulta q. Este modelo assume que a probabilidade de relevância depende somente das representações da consulta e do documento. Este modelo também supõe a existência de um conjunto ótimo de documentos, que maximiza toda a probabilidade de relevância para o usuário. Os documentos deste conjunto são considerados relevantes para uma consulta q e os documentos que não estão neste conjunto são considerados não relevantes [66]. No modelo probabilístico, a similaridade entre um documento d j e uma consulta q é definida por: sim(d j,q) = p(rel d j) p(rel d j ) (2-3) onde: Rel: é o conjunto de documentos que foram estimados como relevantes para a consulta q, isto é, uma estimativa para conjunto ótimo de documentos; Rel: é o conjunto complementar de Rel; P(Rel, d j ): é a probabilidade do documento d j ser relevante para a consulta q;

47 2.5 Recuperação de Informação 46 P(Rel, d j ): é a probabilidade do documento d j não ser relevante para a consulta q. Existem diferentes alternativas para se computar as probabilidades P(Rel, d j ) e P(Rel, d j ) [51]. A medida BM25 [132] [133] é uma das mais bem sucedidas funções de ordenação para o modelo probabilístico. O esquema de ponderação de BM25 é uma função do número de ocorrências de um termo em um documento, na coleção e uma função do tamanho do documento. A variação mais conhecida de BM25 [132] é apresentada a seguir: sim(d j,q) = w (1) (k 1 + 1) t f t q k 1 ((1 b) + b (dl/avgdl)) +t f (k 3 + 1) qt f k 3 + qt f (2-4) onde: t f é a frequência do termo t no documento d j; qt f é a frequência do termo t em uma consulta q; dl e avgdl são, respectivamente, o tamanho do documento d j e o tamanho médio dos documentos da coleção; k1, k3 e b são parâmetros que permitem um ajuste da função de ordenação, de acordo com a consulta e a coleção de documentos. A Equação 2-4 apresenta w (1), que é o peso de um termo t em uma consulta q, definido por Robertson/Sparck-Jones [131]: w (1) = (r + 0.5)/(R r + 0.5) (n r + 0.5)/(N n R + r + 0.5) (2-5) onde: N é o número de documentos de uma coleção; n é o número de documentos que possuem o termo t; R é o número de documentos relevantes para a consulta q; r é o número de documentos relevantes contendo o termo t. Em uma situação prática, como não se sabe previamente quais documentos são relevantes, o conjunto ótimo de documentos relevantes deve ser inicialmente estimado e melhorado através de interações com o usuário Análise Semântica Latente A Análise Semântica Latente (Latent Semantic Analysis LSA) [45], [136], [153] é um método utilizado para a construção de um espaço semântico, onde qualquer

48 2.5 Recuperação de Informação 47 conjunto de palavras pode ser representado por vetores. A suposição é que palavras que tendem a ocorrer juntas dentro de um mesmo documento são consideradas como tendo alguma relação de similaridade semântica [171]. O modelo matemático que se utiliza para criar a estrutura semântica é o método matemático da Álgebra Linear da Decomposição do Valor Singular (Single Value Decomposition) [46]. O resultado da aplicação deste modelo, após a realização de operações matriciais, é a extração de uma estrutura latente ( oculta ) semântica, que refere-se a relações termo-documento, termo-termo ou documento-termo. A maior contribuição do método de Análise Semântica Latente é que consultas e documentos não precisam possuir termos em comum para serem considerados semelhantes. Caso o vetor de consulta e o vetor de um documento estejam próximos no espaço geométrico semântico, o documento é considerado similar à consulta Medidas de Avaliação O desempenho de um sistema de recuperação de informação é avaliado de acordo com a sua capacidade em recuperar o maior número de itens relevantes, ao mesmo tempo em que filtra ao máximo os itens irrelevantes. As métricas usuais para a avaliação do resultado de um sistema de recuperação de informação são: cobertura (recall) e precisão (precision). Para que estas medidas sejam relevantes, é necessário conhecer bem o conteúdo dos documentos da coleção. Estas métricas de avaliação são definidas como: Cobertura: mede a habilidade do sistema em recuperar os documentos mais relevantes para o usuário. Cobertura = n-recuperados-relevantes n-possíveis-relevantes (2-6) onde: n-recuperados-relevantes: é o número de documentos relevantes recuperados. n-possíveis-relevantes: é o número de total de documentos relevantes da coleção. Essa informação geralmente não é conhecida e só pode ser estimada estatisticamente. Precisão: mede a habilidade do sistema manter os documentos irrelevantes fora do resultado de uma consulta. Precisão = n-recuperados-relevantes n-total-recuperados (2-7) onde:

49 2.5 Recuperação de Informação 48 n-total-recuperados: é o número de total de documentos recuperados. Para aumentar a precisão de uma busca, um sistema de recuperação de informação deve ser capaz de descartar itens recuperados que não são relevantes. Para isso, deve-se saber contextualizar os dados recuperados, de forma a identificar falsos relacionamentos que levaram à inclusão inicial de um documento no conjunto de itens recuperados. Para melhorar a cobertura, o sistema deve perceber a relevância dos documentos de uma forma não explícita. Em ambos os casos, o conhecimento do domínio da aplicação pode ajudar [34].

50 Open Archives Initiative CAPÍTULO 3 Este Capítulo apresenta a Open Archives Initiative (OAI), que desenvolve e promove padrões de interoperabilidade entre repositórios digitais, com o objetivo de facilitar a disseminação eficiente de conteúdo. O movimento OAI tem as suas raízes no esforço de ampliar o acesso a repositórios digitais, como um meio de aumentar a disponibilidade da comunicação científica. Na Seção 3.1 é apresentado um breve histórico da Open Archives Initiative. Na Seção 3.2 são apresentadas as principais características da OAI. Na Seção 3.3 é apresentada a arquitetura dos Open Archives. Na Seção 3.4 é apresentado o protocolo OAI-PMH. Na Seção 3.5 são apresentados os verbos de requisição do protocolo OAI-PMH. Na Seção 3.6 são apresentadas algumas ferramentas implementadas pela comunidade OAI. Finalmente, na Seção 3.7 são apresentados alguns passos a serem implementados para a utilização do protocolo OAI-PMH. 3.1 Breve Histórico da Open Archives Initiative O modelo Open Archives surgiu como uma necessidade para prover interoperabilidade entre repositórios digitais, possibilitando o acesso ao acervo de informações neles existentes, de forma integrada por parte dos usuários. No início da década de 90, o Laboratório Nacional de Los Alamos, nos Estados Unidos, construiu e implantou o repositório digital arxiv [10]. A ideia era experimentar uma alternativa para a comunicação científica, de forma a agilizar a publicação dos resultados de pesquisas e facilitar o seu acesso pela comunidade. Assim, os pesquisadores de qualquer parte do mundo ganharam a oportunidade de depositar os seus resultados de pesquisas em um repositório digital de livre acesso. Em contrapartida, os usuários nessa experiência têm a possibilidade de comentar os trabalhos depositados. Para os autores, é disponibilizada a possibilidade de submeter uma nova versão com base nesses comentários. O sucesso dessa experiência estimulou outras áreas a criarem seus próprios repositórios. O surgimento de diversos repositórios dificulta ao usuário o acesso integrado

51 3.2 Principais Características da Open Arquives Initiative 50 ao conjunto de informações neles existente. Para fazer uma mesma consulta, os usuários devem conhecer todos os repositórios, tendo que acessar individualmente cada um deles. Em julho de 1999, foi realizada a Convenção de Santa Fé (Novo México), com o objetivo de desenvolver e promover padrões de interoperabilidade entre repositórios digitais, facilitando a disseminação eficiente de conteúdo. Como resultado dessa reunião, foi constituída a Open Archives Initiative (OAI), cuja meta principal foi contribuir para a transformação da comunicação científica. A linha de ação proposta para essa mudança é a definição de aspectos técnicos e de suporte organizacional de uma estrutura de publicação científica aberta [50]. Essa iniciativa estabeleceu as especificações técnicas e os princípios administrativos formalizando o chamado modelo Open Archives, o qual possibilita um alto nível de interoperabilidade funcional entre esses repositórios. 3.2 Principais Características da Open Arquives Initiative A OAI possui quatro características principais, que especificam sua usabilidade e disponibilidade [84]: auto-arquivamento: é uma característica que permite que o autor tenha autonomia para editorar e arquivar seus textos. Esta liberdade permite em alguns casos, ratificações e atualizações da obra, valorizando o conteúdo informacional; interatividade: é uma característica que diz respeito à interação entre a comunidade acadêmica, possibilitando a troca de informações, críticas, comentários e sugestões do texto disponível neste sistema. Esta forma de comunicação garante legitimidade e aponta o prestígio e aceitação das informações contidas no texto. Isto acontece através de convergências e confrontos de ideias, discussões, críticas e consensos entre a comunidade participante; interdisciplinaridade: é uma característica do sistema caracterizada pelas diversas áreas do conhecimento presentes em um repositório digital; interoperabilidade: é uma característica que objetiva configurar todos os arquivos, através de uma padronização global, para que o acesso a eles seja ilimitado, sem restrições de plataformas. 3.3 Arquitetura dos Open Archives A elaboração de formas mais eficientes para comunicação científica é imprescindível para o desenvolvimento da ciência. Os Open Archives são uma realidade e estão em processo de adaptação para atender às necessidades dos pesquisadores. Para isso, a

52 3.3 Arquitetura dos Open Archives 51 comunidade científica está criando um conjunto de iniciativas com o intuito de tornar esta prática acessível e viável para todos [84]. Kuramoto [50] trata da questão da democratização da informação utilizando os Open Archives, afirmando que: Os Open Archives podem ser uma efetiva ação de inclusão. À medida que é facilitado o acesso à informação com os repositórios livres, qualquer um pode acessar as informações que estão nestes repositórios. Tanto aqueles que têm acesso às revistas estrangeiras, quanto àqueles que não têm. Os Open Archives são um forte instrumento de inclusão e não de exclusão. Quanto maior o acesso público à informação, maior será a possibilidade de ampliarmos a comunidade de usuários, até mesmo de levar esta informação para as comunidades que não têm este acesso. Provavelmente, a maior contribuição da OAI foi a elaboração do protocolo OAI- PMH. No restante desta seção são apresentados alguns conceitos e definições referentes a arquitetura dos Open Archives, que são úteis para o entendimento deste protocolo Provedores de Dados Os provedores de dados são sistemas que utilizam o protocolo OAI-PMH, como um meio de expor seus metadados. Esses provedores também podem (mas não necessariamente) oferecer acesso aberto a textos completos e a outros recursos, sendo os responsáveis por gerenciar os objetos, expondo seus metadados para a coleta. Os provedores de dados são os criadores e mantenedores dos metadados e dos recursos de seus repositórios. Um provedor de dados pode adotar a utilização do protocolo OAI-PMH por diversas razões, como por exemplo [98]: utilização do protocolo como um meio de aumentar a exposição de seus trabalhos; interesse nas funcionalidades oferecidas por determinados provedores de serviços; utilização do protocolo como um meio de compartilhar conhecimento. A Figura 3.1 apresenta um exemplo do fluxo de informação nos provedores de dados. Neste exemplo, os autores realizam o gerenciamento de seus objetos (depósito e editoração dos eprints), enquanto os provedores de dados fazem o controle dos recursos e expõem seus metadados para coleta. O fluxo de informação nos provedores de dados mostra que a simplicidade existente no processo de auto-arquivamento e a possibilidade de editoração dos eprints por parte dos autores otimizam as atividades referentes à exposição de seus trabalhos [84].

53 3.3 Arquitetura dos Open Archives 52 Figura 3.1: Fluxo de informação nos provedores de dados Os provedores de dados que estão em conformidade com o protocolo OAI-PMH podem registrar-se em uma lista de acesso público, através de uma página web [94]. O registro nesta base de dados torna possível aos provedores de serviços descobrirem repositórios para a coleta de metadados Harvesters Os harvesters são programas que utilizam a interface oferecida pelo protocolo OAI-PMH para realizar a coleta de metadados. Eles importam os metadados dos provedores de dados e oferecem a possibilidade de se construir novos serviços sobre estes metadados coletados. A coleta de metadados pode ser total ou baseada em critérios. Os critérios de coleta são: Coleta baseada em Data (Date-based): serão coletados apenas os metadados incluídos ou alterados de acordo com um intervalo de data especificado. Coleta baseada em Conjuntos (Set-based): serão coletados apenas os metadados de acordo com uma estrutura opcional, que agrupa itens de um repositório para os propósitos de coletas seletivas de registros. Esta estrutura é uma árvore de assuntos que representa a hierarquia do repositório.

54 3.4 O protocolo OAI-PMH Provedores de Serviços Os provedores de serviços utilizam os metadados coletados pelos harvesters, como base para a construção de novos serviços. Como exemplo de um novo serviço pode-se citar um sistema que faz a coleta de metadados em diversos provedores de dados, oferecendo uma interface única de busca transparente e amigável para o usuário final. Na Figura 3.2, apresenta-se um exemplo do fluxo de informação nos provedores de serviços. Neste exemplo, o provedor de serviço solicita metadados aos provedores de dados, obtendo uma resposta em conformidade com o protocolo OAI-PMH. Figura 3.2: Fluxo de informação nos provedores de serviços No esquema apresentado na Figura 3.2, além de terem acesso aos metadados dos provedores de dados, os provedores de serviço têm a possibilidade de agregar valor às informações coletadas. 3.4 O protocolo OAI-PMH O OAI-PMH (Open Archives Initiative Protocol for Metadata Harvesting) é um protocolo que possibilita o compartilhamento de metadados entre os participantes da iniciativa OAI, para qualquer aplicação que se interesse na coleta destes metadados. Essa interface possui duas propriedades:

55 3.4 O protocolo OAI-PMH 54 interoperabilidade: é caracterizada pela obrigatoriedade embutida no protocolo para implementação do padrão Dublin Core [32]. Dessa forma, todos os repositórios que utilizam o protocolo OAI podem trocar metadados; extensibilidade: é caracterizada pela possibilidade de se criar ou utilizar padrões de metadados diferentes do Dublin Core. Esta propriedade permite que novos padrões de metadados possam ser criados ou adaptados como alternativa para satisfazer alguma necessidade especial, de forma a funcionarem com o protocolo OAI-PMH. Dessa forma, os metadados disponibilizados pelos provedores de dados podem estar em qualquer formato previamente definido por uma comunidade, embora o padrão Dublin Core seja especificado para fornecer um nível básico de interoperabilidade. Um repositório que implementa o protocolo OAI-PMH não é necessariamente um repositório de acesso aberto. Este protocolo consiste apenas na abertura dos metadados e não necessariamente na abertura do texto completo dos trabalhos presentes nos repositórios. O contrário também é verdade, isto é, existem repositórios de acesso aberto que não implementam o protocolo OAI-PMH [39] Esquema Básico do Protocolo OAI-PMH O OAI-PMH é um protocolo que fornece uma interface bastante simples, para que os provedores de dados tornem seus metadados disponíveis aos provedores de serviços. Na Figura 3.3, apresenta-se o esquema básico de funcionamento do protocolo OAI-PMH. Neste esquema, o provedor de serviço realiza uma requisição baseada em HTTP (Hypertext Transfer Protocol) e obtém uma resposta codificada em XML. Em seguida, o provedor de serviço disponibiliza um novo serviço com valor agregado aos usuários. Figura 3.3: Esquema básico de funcionamento do protocolo OAI- PMH O OAI-PMH define uma interface para a coleta de metadados no formato XML, mas não oferece nenhuma interface para a manipulação dos objetos reais dos repositórios.

56 3.5 Verbos de Requisição do Protocolo OAI-PMH 55 Havendo interesse no acesso ao conteúdo associado aos metadados coletados, podese utilizar os hiperlinks apontadores para os objetos, através dos metadados fornecidos pelos provedores de dados. O padrão Dublin Core possui um elemento identificador (identifier), que pode ser utilizado para este propósito. 3.5 Verbos de Requisição do Protocolo OAI-PMH O protocolo OAI-PMH é um mecanismo para transferência de metadados entre repositórios digitais. A comunicação é realizada através de requisições HTTP, baseadas em perguntas-respostas (request-response). A resposta de cada requisição é retornada no formato XML. Nesta seção, são apresentados os verbos de requisição (comandos transmitidos aos repositórios) do protocolo OAI-PMH. Como provedor de dados, para a construção dos exemplos que simulam o processo de coleta de metadados, utilizou-se a Biblioteca Digital de Teses e Dissertações da UFPR [13]. O protocolo OAI-PMH possui seis verbos (Identify, ListMetadataFormats, ListRecord, ListIdentifier, GetRecord e ListSets), que são descritos a seguir. Para cada verbo, apresenta-se uma ou mais requisições. No Apêndice A, são apresentados trechos das respectivas respostas codificadas em XML Identify Este verbo é utilizado para recuperar informações que descrevem o repositório. Algumas informações retornadas são obrigatórias, como parte da especificação do protocolo. Os repositórios também podem utilizar o verbo Identify para retornar informações adicionais, que complementam a descrição dos mesmos. Argumentos Nenhum Erros e Condições de Exceção badargument: a requisição contêm argumentos ilegais. Formato de Resposta A resposta da requisição do verbo Identify retorna uma instância dos seguintes elementos: repositoryname: o nome do repositório, de uma forma legível por seres humanos; baseurl: o URL base do repositório;

57 3.5 Verbos de Requisição do Protocolo OAI-PMH 56 protocolversion: a versão do protocolo OAI-PMH implementada pelo repositório; earliestdatestamp: a data e hora estabelecida como limite inferior do registro das modificações do repositório, no formato UTCdatetime. Um repositório não deve aceitar datas inferiores ao especificado no campo earliestdatestamp; deletedrecord: a forma pela qual o repositório implementa a noção de registros removidos. Os valores retornados corretamente são: no (nenhum); transient (provisório) e persistent (persistente); granularity: a granularidade dos parâmetros de data utilizados pela coleta seletiva de metadados implementada pelo repositório. Os valores retornados corretamente são: YYYY-MM-DD e YYYY-MM-DDThh:mm:ssZ. A resposta da requisição do verbo Identify retorna uma ou mais instâncias do seguinte elemento: admin o endereço de do administrador do repositório. A resposta da requisição do verbo Identify retorna múltiplas instâncias dos seguintes elementos opcionais: compression: a compressão implementada pelo repositório; description: um mecanismo adicional para descrever o repositório. Exemplo de Requisição Requisição 1 Recupera informações que descrevem o repositório. Um trecho da resposta em XML é apresentado pelo Código A.1, no Apêndice A ListMetadataFormats Este verbo é utilizado para listar os padrões de metadados implementados pelo repositório. Destaca-se a obrigatoriedade da implementação do padrão Dublin Core. Argumentos identifier: é um argumento opcional, que especifica o identificador de um objeto do repositório, no qual se deseja listar os padrões de metadados implementados por este objeto em particular. Quando este argumento é omitido, a resposta incluirá todos os padrões de metadados implementados pelo repositório. O fato de um padrão de metadado ser implementado por um repositório não significa que ele pode ser disseminado para todos os objetos deste repositório.

58 3.5 Verbos de Requisição do Protocolo OAI-PMH 57 Erros e Condições de Exceção badargument: a requisição contêm argumentos ilegais ou estão faltando argumentos obrigatórios; iddoesnotexist: o valor do argumento identifier é desconhecido ou ilegal nesse repositório; nometadataformats: não existe nenhum padrão de metadado disponível para o objeto especificado. Exemplos de Requisições Requisição 2 Lista todos os padrões de metadados implementados pelo repositório. Um trecho da resposta em XML é apresentado pelo Código A.2, no Apêndice A. verb=listmetadataformats Requisição 3 Lista todos os padrões de metadados implementados pelo objeto com identificador oai:dspace.c3sl.ufpr.br:1884/335. Um trecho da resposta em XML é apresentado pelo Código A.3, no Apêndice A. verb=listmetadataformats& identifier=oai:dspace.c3sl.ufpr.br:1884/335 Requisição 4 Lista todos padrões de metadados implementados pelo objeto com identificador oai:dspace.c3sl.ufpr.br:0000/171. No entanto, o identificador fornecido não existe nesse repositório. A resposta desta requisição conterá um elemento error no código XML retornado, com uma mensagem informando que o identificador fornecido é desconhecido ou ilegal nesse repositório. A resposta em XML é apresentada pelo Código A.4, no Apêndice A. verb=listmetadataformats& identifier=oai:dspace.c3sl.ufpr.br:0000/ ListRecords Este verbo é utilizado para a coleta de metadados em um repositório. Através de argumentos opcionais, pode-se realizar coletas seletivas baseadas em data ou em conjuntos. Dependendo do repositório, o cabeçalho retornado para um objeto pode conter o atributo status como deleted, se este objeto tiver sido removido do repositório. Nenhum item de metadado será retornado para objetos com o estado removido.

59 3.5 Verbos de Requisição do Protocolo OAI-PMH 58 Argumentos from: é um argumento opcional, com um valor UTCdatetime, que especifica o limite inferior para coletas seletivas baseadas em datas; until: é um argumento opcional, com um valor UTCdatetime, que especifica o limite superior para coletas seletivas baseadas em datas; set: é um argumento opcional, com um valor setspec, que especifica um conjunto para coleta seletiva; resumptiontoken: é um argumento com um valor único, relativo ao fluxo de controle retornado pela requisição ListRecords anterior, que emitiu uma listagem incompleta; metadataprefix: é um argumento obrigatório (a menos que o argumento resumptiontoken seja utilizado), que especifica o padrão do metadataprefix que deve ser incluído como parte dos metadados dos registros retornados. Os registros deverão ser incluídos apenas para os objetos onde o padrão do metadado informado pode ser disseminado. Os padrões de metadados implementados pelo repositório e para um objeto particular podem ser descobertos utilizando o verbo ListMetadataFormats. Erros e Condições de Exceção badargument: a requisição contêm argumentos ilegais ou estão faltando argumentos obrigatórios; badresumptiontoken: o valor do argumento resumptiontoken é inválido ou expirou; cannotdisseminateformat: o valor do argumento metadataprefix não é implementado por este repositório; norecordsmatch: a combinação dos valores dos argumentos from, until, set e metadataprefix resultaram em uma listagem vazia; nosethierarchy: este repositório não implementa conjuntos. Exemplos de Requisições Requisição 5 Lista os metadados no padrão oai_dc de todos os objetos do repositório. Um trecho da resposta em XML é apresentado pelo Código A.5, no Apêndice A. verb=listrecords&metadataprefix=oai_dc Requisição 6 Lista os metadados no padrão oai_dc de todos os objetos que foram modificados ou adicionados entre as datas T17:19:22Z e

60 3.5 Verbos de Requisição do Protocolo OAI-PMH T17:51:55Z. Um trecho da resposta em XML é apresentado pelo Código A.6, no Apêndice A. verb=listrecords&from= t17:19:22z& until= t17:51:55z&metadataprefix=oai_dc Requisição 7 Lista os metadados no padrão oai_dc de todos os objetos que pertencem ao conjunto identificado por hdl_1884_289. Os conjuntos dos repositórios podem ser descobertos utilizando o verbo ListSets. Ao fazer uma requisição com o verbo ListSets, pode-se verificar que o nome do conjunto do repositório identificado por hdl_1884_289 é TV UFPR. Um trecho da resposta em XML é apresentado pelo Código A.7, no Apêndice A. verb=listrecords&set=hdl_1884_289& metadataprefix=oai_dc ListIdentifiers Este verbo é uma versão abreviada do verbo ListRecords, que retorna apenas os cabeçalhos dos objetos. Através de argumentos opcionais, pode-se realizar coletas seletivas de metadados, baseada em data ou em conjuntos. Dependendo do repositório, o cabeçalho retornado para um objeto pode conter o atributo status como deleted, se este objeto tiver sido removido do repositório. Nenhum item de metadado será retornado para objetos com o estado removido. Argumentos from: é um argumento opcional, com um valor UTCdatetime, que especifica o limite inferior para coletas seletivas baseadas em datas; until: é um argumento opcional, com um valor UTCdatetime, que especifica o limite superior para coletas seletivas baseadas em datas; set: é um argumento opcional, com um valor setspec, que especifica um conjunto de critérios para coletas seletivas; resumptiontoken: é um argumento com um valor único, relativo ao fluxo de controle retornado pela requisição ListIdentifiers anterior, que emitiu uma listagem incompleta; metadataprefix: é um argumento obrigatório (a menos que o argumento resumptiontoken seja utilizado) que especifica o padrão do metadataprefix que deve ser incluído como parte dos metadados dos registros retornados. Os registros deverão ser incluídos apenas para os objetos onde o padrão do metadado

61 3.5 Verbos de Requisição do Protocolo OAI-PMH 60 informado pode ser disseminado. Os padrões de metadados implementados pelo repositório e para um objeto particular podem ser descobertos utilizando o verbo ListMetadataFormats. Erros e Condições de Exceção badargument: a requisição contêm argumentos ilegais ou estão faltando argumentos obrigatórios; badresumptiontoken: o valor do argumento resumptiontoken é inválido ou expirou; cannotdisseminateformat: o valor do argumento metadataprefix não é implementado por este repositório; norecordsmatch: a combinação dos valores dos argumentos from, until, set e metadataprefix resultaram em uma listagem vazia; nosethierarchy: este repositório não implementa conjuntos. Exemplos de Requisições Requisição 8 Lista os metadados no padrão oai_dc, relativos ao cabeçalho de todos os objetos do repositório. Um trecho da resposta em XML é apresentado pelo Código A.8, no Apêndice A. verb=listidentifiers&metadataprefix=oai_dc Requisição 9 Lista os metadados no padrão oai_dc, relativos ao cabeçalho de todos os objetos que foram modificados ou adicionados entre as datas T17:19:22Z e T17:51:55Z. Um trecho da resposta em XML é apresentado pelo Código A.9, no Apêndice A. verb=listidentifiers&from= t17:19:22z& until= t17:51:55z&metadataprefix=oai_dc Requisição 10 Lista os metadados no padrão oai_dc, relativos ao cabeçalho de todos os objetos que pertencem ao conjunto identificado por hdl_1884_289. Um trecho da resposta em XML é apresentado pelo Código A.10, no Apêndice A. verb=listidentifiers&set=hdl_1884_289& metadataprefix=oai_dc

62 3.5 Verbos de Requisição do Protocolo OAI-PMH GetRecord Este verbo é utilizado para recuperar os metadados de um objeto particular. Os argumentos obrigatórios devem especificar o identificador do objeto e o padrão de metadados que se deseja recuperar. Argumentos identifier: é um argumento obrigatório, com um identificador único, que determina o objeto do qual se pretende recuperar os metadados; metadataprefix: é um argumento obrigatório, que especifica o padrão do metadataprefix que deve ser incluído como parte dos metadados dos registros retornados. Os registros deverão ser incluídos apenas para os objetos onde o padrão do metadado informado pode ser disseminado. Os formatos de metadados implementados pelo repositório e para um objeto particular podem ser descobertos utilizando o verbo ListMetadataFormats. Erros e Condições de Exceção badargument: a requisição contêm argumentos ilegais ou estão faltando argumentos obrigatórios; cannotdisseminateformat: o valor do argumento metadataprefix não é implementado por este repositório; iddoesnotexist: o valor do argumento identifier é desconhecido ou ilegal neste repositório. Exemplos de Requisições Requisição 11 Recupera os metadados no padrão oai_dc do objeto identificado por oai:dspace.c3sl.ufpr.br:1884/335. Um trecho da resposta em XML é apresentado pelo Código A.11, no Apêndice A. verb=getrecord&identifier=oai:dspace.c3sl.ufpr.br:1884/335& metadataprefix=oai_dc Requisição 12 Recupera os metadados no padrão oai_dc do objeto identificado por oai:dspace.c3sl.ufpr.br:0000/171. No entanto, o identificador fornecido não existe neste repositório. A resposta desta requisição conterá um elemento error no XML retornado, com uma mensagem informando que o identificador fornecido é desconhecido ou ilegal neste repositório. A resposta em XML é apresentada pelo Código A.12, no Apêndice A. verb=getrecord&identifier=oai:dspace.c3sl.ufpr.br:0000/171& metadataprefix=oai_dc

63 3.6 Ferramentas Implementadas pela Comunidade OAI 62 Requisição 13 Recupera os metadados no padrão oai_marc do objeto identificado por oai:dspace.c3sl.ufpr.br:1884/335. No entanto, o padrão de metadado informado (oai_marc) não é implementado por este repositório. A resposta desta requisição conterá um elemento error no XML retornado, com uma mensagem informando que o padrão de metadado fornecido não é implementado pelo objeto ou pelo repositório. A resposta em XML é apresentada pelo Código A.13, no Apêndice A. verb=getrecord&identifier=oai:dspace.c3sl.ufpr.br:1884/335& metadataprefix=oai_marc ListSets Este verbo lista os conjuntos de um repositório (também conhecido como árvore de assuntos ou hierarquia do repositório), útil para a coleta seletiva de metadados. Argumentos resumptiontoken: é um argumento com um valor único, relativo ao fluxo de controle retornado pela requisição ListSets anterior, que emitiu uma listagem incompleta. Erros e Condições de Exceção badargument: a requisição contêm argumentos ilegais ou estão faltando argumentos obrigatórios; badresumptiontoken: o valor do argumento resumptiontoken é inválido ou expirou; nosethierarchy: este repositório não implementa conjuntos. Exemplo de Requisição Requisição 14 Lista os conjuntos do repositório. Um trecho da resposta em XML é apresentado pelo Código A.14, no Apêndice A Ferramentas Implementadas pela Comunidade OAI Existem diversas ferramentas implementadas por colaboradores da comunidade OAI, com o objetivo de apoiar o desenvolvimento desta iniciativa. Na Seção foram apresentados diversas ferramentas que permitem a implementação de repositórios digitais.

64 3.6 Ferramentas Implementadas pela Comunidade OAI 63 A seguir, apresenta-se uma descrição resumida de outras ferramentas específicas com relação ao protocolo OAI-PMH, implementadas por colaboradores da comunidade OAI. Todas estas ferramentas implementam alguma versão do protocolo OAI-PMH. A descrição completa sobre cada ferramenta pode ser encontrada em suas respectivas páginas web. Kepler [62]: é um projeto que introduz a idéia de redes peer-to-peer para a iniciativa Open Archives, desenvolvido pela Old Dominion University. Este projeto possibilita a participação de pequenos grupos ou mesmo indivíduos na iniciativa, sem a necessidade de uma infra-estrutura para manter um repositório de documentos na Internet. OAICat [92]: o OAICat é um software desenvolvido com a tecnologia de Servlet em Java, que implementa suporte ao protocolo OAI-PMH em repositórios de dados já existentes, desenvolvido pela OCLC (Online Computer Library Center). O OAICat foi desenvolvido em conformidade com a versão 2.0 do protocolo OAI-PMH. PEAR::OAI [109]: é uma biblioteca em PHP (baseada em PERL), construída em conformidade com o protocolo OAI-PMH para implementação de harvesters, desenvolvida pela ZZ/OSS Information Networking. phpoai2 [112]: é uma implementação em PHP da interface do protocolo OAI- PMH para provedores de dados que desejam expor seus metadados através deste protocolo, disponibilizada pelo Institute for Science Networking Oldenburg. PKP Open Archives Harvester [113]: é um sistema de código aberto para indexação de metadados, desenvolvido pela Public Knowledge Project. Repository Explorer [126]: é uma ferramenta web, inicialmente desenvolvida pela DLRL (Digital Library Research Laboratory) da Virginia Tech, que possibilita a verificação interativa da validade da implementação do protocolo OAI-PMH para um determinado repositório. Atualmente, esta ferramenta é mantida pela AIM (Advanced Information Management laboratory) da University of Cape Town. RVOT [130]: o RVOT (Rapid Visual OAI Tool) é uma ferramenta utilizada para a construção gráfica de repositórios em conformidade com o protocolo OAI-PMH, através de uma coleção de dados. O RVOT foi desenvolvido pela Old Dominion University. ZMARCO [175]: é um provedor de dados em conformidade com o protocolo OAI-PMH. O Z em ZMARCO se refere ao protocolo Z39.50, MARC se refere a Machine Readable Cataloging e O se refere a Open Archives Inititive. O ZMARCO foi desenvolvido pela University of Illinois em Urbana-Champaign, fundado pela Andrew Mellon Foundation.

65 3.7 Etapas para a Utilização do Protocolo OAI-PMH Etapas para a Utilização do Protocolo OAI-PMH A principal finalidade do protocolo OAI-PMH é facilitar o compartilhamento de metadados, proporcionando a coleta e disseminação desses metadados para criação de novos serviços. Existem alguns passos a serem implementados para uma coleta eficiente de metadados. Algumas destas etapas são apresentadas a seguir [39]: seleção: processo de escolha dos repositórios e identificação dos respectivos URLs base de coleta (ou seja, os URLs nos quais é possível aplicar os verbos de requisições), para os repositórios onde se deseja coletar os metadados; ferramentas para harvester: nesta etapa, deve-se escolher as ferramentas apropriadas para os harvester; coleta de metadados: processo de coleta de metadados, através de uma lista com os URLs base dos repositórios fornecedores de metadados; normalização dos metadados: processo de normalização dos metadados coletados, de forma a se tornarem úteis para a implementação dos serviços pretendidos. A seguir são apresentadas algumas considerações e dificuldades identificadas em cada uma destas etapas [39] Seleção Esta etapa é responsável pelo processo de escolha dos repositórios e identificação dos respectivos URLs da base de coleta, ou seja, as URLs a partir das quais é possível aplicar os verbos de requisições para coletar os metadados de um determinado repositório. Pela resposta do verbo Identify, apresentado na seção 3.5.1, é possível descobrir algumas informações sobre a natureza dos dados contidos nos repositórios. No entanto, frequentemente esses dados são insuficientes para tomar a decisão se um determinado repositório é de real interesse para realizar a coleta de seus metadados. Para se tomar uma decisão, é necessária a intervenção humana, através do processo de navegação pelos recursos do repositório. Deve-se checar a qualidade do conteúdo e a clareza da implementação de seus metadados. O desenvolvimento de ferramentas computacionais que automatizem essa etapa é algo bastante complexo, principalmente porque o tema e a qualidade do repositório são critérios subjetivos e sujeitos a debate [39] Ferramentas para os Harvester No portal de ferramentas da OAI, encontram-se diversas ferramentas para a implementação de harvesters de licença livre. As funcionalidades e desempenho destas

66 3.7 Etapas para a Utilização do Protocolo OAI-PMH 65 ferramentas variam. Dessa forma, elas devem ser bem analisadas e testadas, de acordo com os requisitos particulares de cada organização. Como exemplo de ferramentas para a implementação de harvesters, cita-se as ferramentas apresentadas na Seção Coleta de Metadados O processo de coleta de metadados é realizado através de uma lista com os URLs base dos repositórios provedores de dados. Apesar da interface do protocolo OAI-PMH oferecer um conjunto de verbos que facilitam a coleta automática dos metadados, ainda surgem alguns problemas como [39]: mudança do URL base do repositório: para a coleta de metadados através do protocolo OAI-PMH é necessário fornecer um URL ao programa harvester, no qual se aplicará os verbos de requisição. Porém, às vezes, o URL do repositório muda e nem sempre é fácil descobrir o novo URL; servidor fora do ar: algumas instituições oferecem pouca manutenção e sustentação do serviço, o que pode inviabilizar a coleta de metadados; falhas na implementação da interface OAI: alguns repositórios não respondem corretamente aos seis verbos de requisição do protocolo OAI-PMH; interrupção na coleta por sobrecarga do servidor: por receberem muitas requisições de harvesters, alguns servidores caem e interrompem a transferência dos metadados antes que a transferência seja concluída. Os problemas citados tornam-se ainda mais graves na medida em que o número de repositórios fornecedores de metadados aumenta, tornando a etapa de coleta de metadados muito exaustiva Normalização dos Metadados Devido à heterogeneidade na implementação do padrão Dublin Core, os metadados necessitam ser normalizados, para de fato tornarem-se úteis. Na realidade, o protocolo OAI-PMH não implementa exatamente o padrão Dublin Core. Ele implementa o padrão oai_dc, que considera um subconjunto de campos do Dublin Core. A diferença entre o Dublin Core e o oai_dc é que, no último, a implementação de alguns campos se torna obrigatória. São eles: title, creator, subject, description, publisher, date, type, identifier, relation e language. Sobre a qualidade dos metadados, os desenvolvedores do NSDL (National Science Digital Library) comentam [168]:

67 3.7 Etapas para a Utilização do Protocolo OAI-PMH 66 A qualidade dos registros de metadados é extremamente variável de um repositório para outro, havendo necessidade de uma quantidade não-trivial de esforço humano para torná-lo aproveitável. Existem algumas recomendações de implementação de metadados para a Open Archives Initiative, feitas por Andy Powell et. al [4]. Estas recomendações são significativas, do ponto de vista das informações necessárias para que, tanto um robô quanto um ser humano, sejam capazes de extrair dados importantes para avaliação do documento. Porém, estas recomendações são muito pouco seguidas, mesmo pelos maiores e mais importantes repositórios de artigos científicos de acesso aberto. Em alguns importantes repositórios, como arxiv [10], Pubmed Central [116], CiteSeer [19], Cogprints [21], o repositório ECS EPrints [33], os campos title e description são frequentemente bem implementados, seguindo as recomendações de Andy Powell et. al. Eles contêm respectivamente o título e o resumo do artigo. No entanto, há muita confusão no campo date, que pode se referir a data de publicação na revista, a disponibilização do artigo no repositório digital ou até mesmo a data de criação do documento. Como exemplo das divergências identificadas na implementação de metadados por repositório institucionais, podem ser citados o repositório de Southampton, o Cogprints e o DSpace do MIT. O repositório de Southampton, por exemplo, implementa o difundido padrão de classificação Library of Congress. O Cogprints utiliza um esquema especializado nos ramos das suas disciplinas (Ciências Cognitivas e Ciência da Computação). Já o DSpace hospedado pelo MIT, as palavras-chaves são preenchidas no campo subject por seus autores. Somente nestes três exemplos, tem-se três esquemas completamente diferentes [20]. Em sua última versão, o software EPrints incorporou um dos melhores e mais famosos padrões de classificação, conhecido como Library of Congress. Porém, para muitas áreas especializadas da Ciência, essa árvore não é suficientemente ramificada, abrangendo apenas os assuntos mais gerais. Para a área de Ciência da Computação, por exemplo, ela não é tão detalhada quanto necessário. Essas deficiências podem ser diminuídas como uso de ferramentas computacionais sofisticadas. Uma possível solução seria encontrar automaticamente as palavraschaves a partir dos documentos completos e utilizá-las para inferir sobre o assunto. Ainda não existe nenhuma ferramenta desse tipo entre as ferramentas de apoio da Open Archives Initiative [20].

68 Desenvolvimento do Sistema CAPÍTULO 4 Este Capítulo apresenta as etapas implementadas para a construção do sistema desenvolvido nesta dissertação, com o propósito de possibilitar a recuperação contextualizada de documentos em um conjunto de bibliotecas digitais, repositórios e outros provedores de dados, integrados por meio do protocolo OAI-PMH. Na Seção 4.1 é apresentada a arquitetura do sistema desenvolvido. Na Seção 4.2 é apresentado o módulo responsável pela integração de Provedores de Dados. Na Seção 4.3 é apresentado o módulo responsável pela recuperação contextualizada de documentos em um banco de dados integrado. Na Seção 4.4 é apresentada a implementação de uma interface via web services, referente às principais funcionalidades do processo de recuperação contextualizada de documentos. Na Seção 4.5 é apresentada a implementação da interface de busca, construída em ambiente web (através dos serviços disponibilizados pelo desenvolvimento da interface via web services), que permite a interação de usuários com o módulo de recuperação contextualizada de documentos. 4.1 Arquitetura do Sistema A arquitetura do sistema desenvolvido foi dividida em dois módulos, conforme pode ser observado na Figura 4.1. O primeiro módulo é responsável pela integração de provedores de dados e o segundo pela recuperação de documentos. Estes dois módulos são apresentados em detalhes nas Seções 4.2 e 4.3. A seguir, apresenta-se uma visão geral de cada módulo da arquitetura do sistema desenvolvido: Integração de Provedores de Dados: este módulo têm como objetivo a integração (através da interface oferecida pelo protocolo OAI-PMH) e pré-processamento de metadados de diversos provedores de dados. Recuperação de Documentos: este módulo têm como objetivo a recuperação de documentos neste repositório integrado, onde as consultas são avaliadas dentro de um contexto especificado por uma ontologia. Neste processo, são utilizados

69 4.2 Integração de Provedores de Dados 68 ambientes wiki como uma base de conhecimento auxiliar, onde são extraídos termos relevantes com relação a uma consulta fornecida por um usuário e a um domínio de conhecimento, que é especificado por uma ontologia. Figura 4.1: Arquitetura do sistema desenvolvido O resultado do processamento do sistema desenvolvido é um ranking de documentos, ordenado por maior grau de relevância com relação à consulta e a um domínio de conhecimento. 4.2 Integração de Provedores de Dados Este módulo têm como objetivo realizar a integração e pré-processamento de metadados de bibliotecas digitais, repositórios, bancos de dados distribuídos, diretórios de arquivos de textos não-estruturados, etc. No contexto deste trabalho, a integração de qualquer provedor de dados é realizada através da utilização da interface oferecida pelo protocolo OAI-PMH. Para as bibliotecas digitais ou repositório que já disponibilizam uma implementação do protocolo OAI-PMH como uma alternativa para a exposição e compartilhamento de seus metadados, o processo de coleta de metadados é realizado utilizando-se o URL base de requisições destes repositórios. Uma alternativa para a descoberta de provedores de dados que estão em conformidade com procolo OAI-PMH e de seus respectivos URLs base de requisições é a consulta de listas de acesso público, disponíveis na Internet. Em janeiro de 2010, a página oficial de registro de provedores de dados da OAI [119] possuía mais de repositórios de diversas instituições de todo o mundo.

70 4.2 Integração de Provedores de Dados 69 Para os repositórios que não possuem uma implementação da interface do protocolo OAI-PMH, pode-se implementar esta interface de duas maneiras: através do desenvolvimento completo da interface com o protocolo OAI-PMH, baseada na documentação disponível pela Open Archives Initiative [93] [97]; através da utilização de ferramentas que implementam a interface com o protocolo OAI-PMH. Para a integração de provedores de dados de interesse experimental deste trabalho que não possuem uma implementação da interface do protocolo OAI-PMH (como por exemplo, bancos de dados distribuídos, diretórios de dados não-estruturados, etc), utilizou-se uma adaptação da ferramenta phpoai2 [112] para cada um destes provedores. Dessa forma, para tornar possível a coleta dos metadados destes provedores de dados, inicialmente foi necessário expor os mesmos. Este processo é apresentado a seguir: Exposição de Metadados: é realizada uma adaptação da ferramenta phpoai2, possibilitando a exposição dos metadados destes provedores de dados, através da implementação de uma interface com o protocolo OAI-PMH. O phpoai2 é uma ferramenta que permite a implementação de provedores de dados, em conformidade com o protocolo OAI-PMH. Coleta de Metadados: o processo de coleta de metadados é realizado utilizandose o novo URL base de requisições, criado a partir da adaptação da ferramenta phpoai2. Como exemplo, na Figura 4.2, é apresentado o processo adotado neste trabalho para a exposição de metadados (ou dados, considerando o seu conteúdo real) de um diretório de dados não-estruturados. Conforme pode ser observado na Figura 4.2, existe um diretório raiz contendo vários sub-diretórios. Cada sub-diretório refere-se a um determinado assunto, contendo vários arquivos de texto plano. No processo de adaptação da ferramenta phpoai2 para a exposição do conteúdo deste diretório, os elementos de metadados são preenchidos da seguinte forma: title: o nome do arquivo de texto plano; subject: o nome do sub-diretório (que refere-se a um determinado assunto) no qual o arquivo está inserido; description: o conteúdo do arquivo; date: a data de exposição do conteúdo do arquivo; type: o tipo do arquivo (txt); format: o formato do arquivo (text/plain); identifier: o endereço físico do arquivo;

71 4.2 Integração de Provedores de Dados 70 language: o idioma do conteúdo do arquivo (pt-br); Figura 4.2: Processo adotado para a exposição de metadados de um diretório de dados não-estruturados Na Figura 4.3, apresenta-se o esquema geral utilizado no processo de integração de provedores de dados, que é utilizado neste trabalho. Figura 4.3: Esquema geral utilizado no processo de integração de provedores de dados Conforme pode ser observado na Figura 4.3, os metadados de diversos provedores de dados são coletados por um harvester, através da utilização dos verbos de requisições do protocolo OAI-PMH. Na Figura 4.4, apresenta-se o algoritmo responsável pela construção deste harvester.

72 4.2 Integração de Provedores de Dados 71 Figura 4.4: Algoritmo responsável pela coleta de metadados dos provedores de dados Analisando o código da Figura 4.4, observa-se nas linhas 2 e 3, a montagem de uma requisição na variável consulta. Na linha 2, verifica-se a existência da variável OAIbaseURL, que contêm o URL base de um provedor de dados em conformidade com o protocolo OAI-PMH. Em seguida, nesta mesma linha, nota-se o verbo de requisição ListRecords, indicando que esta requisição refere-se a uma ação de coleta de metadados. Na linha 3, finalizando a montagem desta requisição, acrescenta-se o metadataprefix=oai_dc, indicando o formado do padrão de metadados que deve ser retornado na resposta desta requisição. Na linha 6, através da função enviar_requisição(), representa-se o processo de envio de uma requisição para um determinado provedor de dados, de acordo com a montagem da requisição atribuída na variável consulta. Na linha 10, inicia-se uma estrutura de repetição, responsável pelo processamento dos metadados coletados. Esta estrutura de repetição é finalizada na linha 35.

73 4.2 Integração de Provedores de Dados 72 Na linha 16, recupera-se o valor do campo resumptiontoken, que é fornecido como resposta da última requisição. Este campo está relacionado ao fluxo de controle do protocolo OAI-PMH. Quando o valor deste campo é diferente de vazio, significa que a resposta da última requisição emitiu uma listagem incompleta e deve-se utilizar este valor para montar uma nova requisição para completar a listagem dos resultados que devem ser retornados. Na linha 20, faz-se a verificação do conteúdo da variável resumptiontoken. Se o conteúdo desta variável é diferente de vazio, então os seguintes passos devem ser executados: na linha 23, a variável continuar recebe o valor verdadeiro, indicando que a estrutura de repetição ainda não deve ser finalizada; nas linhas 27 e 28, monta-se uma nova requisição na variável consulta, utilizando o verbo ListRecords e o parâmetro resumptiontoken. O valor deste parâmetro é definido pelo conteúdo do campo resumptiontoken fornecido como resposta da requisição anterior; na linha 31, através da função enviar_requisição(), representa-se o processo de envio da nova requisição, de acordo com a montagem da requisição atribuída na variável consulta, com o objetivo de completar a listagem dos resultados que não foram retornados pela requisição anterior. Em seguida, o fluxo de execução é desviado, voltando a executar a linha 13. Se o teste condicional da linha 20 retornar o valor falso, então o fluxo de execução do algoritmo é desviado para a linha 33, onde a variável continuar receberá o valor falso. Em seguida, na linha 35, a execução do algoritmo é finalizada. Utilizando o algoritmo da Figura 4.5, os metadados são coletados de diversos provedores de dados (conforme apresentado no esquema da Figura 4.3) e são armazenados em uma base de dados estruturada para sua posterior recuperação. Neste trabalho, utilizou-se o MySQL [86] como sistema gerenciador de banco de dados. Na Figura 4.5, apresenta-se o modelo relacional utilizado no armazenamento dos metadados coletados. Neste modelo, observa-se os seguintes tipos de entidade: msc_repositorios: é responsável pelo armazenamento de informações sobre os provedores de dados, no qual seus metadados já foram coletados pelo sistema desenvolvido; msc_dc: refere-se aos elementos do padrão de metadados Dublin Core; msc_registros: refere-se a cada objeto coletado de um determinado provedor de dados; msc_metadados: refere-se a todos os metadados coletados com relação a um determinado objeto;

74 4.2 Integração de Provedores de Dados 73 msc_consulta: refere-se a todos os metadados pré-processados de um determinado objeto. Neste caso, todos os itens de metadados de um objeto contidos em msc_metadados são pré-processados, concatenados e armazenados como um único registro em msc_consulta. Figura 4.5: Modelo relacional utilizado no armazenamento dos metadados coletados No processo de pré-processamento dos metadados, as seguintes atividades são realizadas: remoção de stopwords (termos irrelevantes); aplicação do processo de stemming (redução dos termos semanticamente relacionados ao mesmo radical); remoção de pontuações; remoção de termos com erros ortográficos (com relação ao idioma Português); remoção de termos que não fazem parte do idioma Português. Para a identificação de stopwords foi utilizada uma lista de termos irrelevantes. Para a aplicação do processo de stemming foi utilizada a implementação opensource do algoritmo de Porter para o idioma Português, denominada PTStemmer [115]. Para a identificação de termos com erros ortográficos ou que não fazem parte do idioma Português foi utilizada a implementação opensource do projeto Jazzy (Java Spell Check API) [56], através de uma adaptação com a utilização de um dicionário da língua portuguesa, o br.ispell [15]. Alguns termos considerados importantes e que não fazem

75 4.3 Recuperação de Documentos 74 parte do idioma Português foram adicionados em uma lista positiva, para que os mesmos não fossem removidos. 4.3 Recuperação de Documentos Este módulo têm como objetivo a recuperação contextualizada de documentos em um repositório de dados integrado. Conforme já foi apresentado na Figura 4.3, este repositório integrado contêm metadados de diversos provedores de dados. A Figura 4.6 apresenta o processo adotado neste trabalho para a recuperação contextualizada de documentos. Figura 4.6: Processo adotado para a recuperação contextualizada de documentos Conforme pode ser observado na Figura 4.6, através de uma interface de consulta, os usuários podem formular suas consultas através da digitação de termos que descrevem o assunto de seu interesse. A consulta informada pelo usuário é envida ao Sistema de Recuperação de Informação (SRI) através de uma requisição via web service [78]. Conforme será apresentado na Seção 4.4, algumas funcionalidades referentes ao processo de recuperação de informação no banco de dados integrado foram disponibilizadas através da implementação de uma interface via web services.

76 4.3 Recuperação de Documentos 75 O SRI realiza seu processamento em duas etapas, responsáveis pela análise e processamento da consulta, que são apresentadas em detalhes nas Seções e A seguir, apresenta-se uma visão geral destas duas etapas: Analisador de Consulta: a consulta enviada por um determinado usuário (através da interface de busca responsável pela requisição ao SRI via web services) é submetida a uma etapa de pré-processamento e expansão. Processador de Consulta: após a consulta ser pré-processada e expandida, é realizado o processamento efetivo para a recuperação de informação. Neste processo, é utilizada uma ontologia e a análise de artigos de ambientes wiki, utilizados como uma base de conhecimento auxiliar, onde são extraídos termos relevantes com relação a uma consulta fornecida por um usuário e a um contexto especificado pela ontologia. Este trabalho não tem como objetivo a construção de ontologias. Neste caso, o interesse com relação a utilização de ontologias está no uso como artefatos de especificação de domínios de conhecimentos. No entanto, para a realização dos experimentos foram implementados fragmentos de ontologias de domínio, onde não foi adotado nenhuma metodologia formal para a sua construção. Estas ontologias foram implementadas em OWL (Web Ontology Language) [102]. Na Figura 4.7, apresenta-se um trecho de uma ontologia desenvolvida para o domínio de Trânsito, utilizando o Protégé [114], que é um ambiente para criação e edição de ontologias e bases de conhecimento. Para a navegação e realização de inferências em ontologias, utilizou-se o Jena (Semantic Web Framework for Java) [57]. Jena é um arcabouço de código aberto desenvolvido pela HP Labs para construção de aplicações voltadas à Web Semântica. Neste trabalho, todos os conceitos das ontologias implementadas para a realização dos experimentos foram preenchidos com uma anotação, que faz a ligação deste conceito com um ou mais artigos de ambientes wiki, implementados pelo software MediaWiki. Na Figura 4.8, apresenta-se a anotação do conceito Automóvel, referente a uma ontologia do domínio de Trânsito.

77 4.3 Recuperação de Documentos 76 Figura 4.7: Trecho de uma ontologia desenvolvida para o domínio de Trânsito Figura 4.8: Anotação do conceito Automóvel, referente a uma ontologia do domínio de Trânsito

78 4.3 Recuperação de Documentos 77 Conforme pode ser observado na Figura 4.8, na anotação do conceito Automóvel existem dois apontamentos: o primeiro para o artigo Automóvel da Wikipédia ( e o segundo para o artigo Carro de uma ambiente wiki local ( Neste caso, no processo de análise do conceito Automóvel (ou Carro, já que analisando a ontologia, observa-se que estes conceitos são equivalentes), considerando esta ontologia do domínio de Trânsito, o sistema desenvolvido deverá consultar estes dois artigos para a extração de termos significativos. Na Figura 4.9, apresenta-se a implementação de um ambiente wiki local, através da utilização do software MediaWiki, que é utilizado neste trabalho para propósitos de experimentação. Figura 4.9: Implementação de um ambiente wiki local, através da utilização do software MediaWiki Através da manipulação de sua API, o sistema desenvolvido neste trabalho pode consultar artigos de qualquer ambiente wiki implementado pelo software MediaWiki.

79 4.3 Recuperação de Documentos Analisador de Consulta Esta etapa tem como objetivo realizar o pré-processamento e expansão das consultas enviadas pelos usuários ao sistema desenvolvido neste trabalho. No processo de pré-processamento da consulta, são removidas as stopwords e realizado o processo de stemming em cada termo. Na expansão da consulta, seus termos são confrontados com uma ontologia. Para cada conceito identificado, é verificada a presença de conceitos equivalentes nesta ontologia, acrescentando-os na consulta original. Como exemplo, observa-se na Figura 4.7 que os conceitos Automóvel e Carro foram definidos como equivalentes. Através da utilização do Jena para a manipulação de ontologias, dado um determinado conceito é possível identificar todos os seus conceitos equivalentes Processador de Consulta Após a consulta ser pré-processada e expandida, é realizado o processamento efetivo para a recuperação de informação. Nessa etapa, os documentos são recuperados do banco de dados integrado, fazendo-se uma comparação entre os termos da consulta expandida e os termos de cada documento. Construção da expressão booleana para a Recuperação de Documentos Para a recuperação dos documentos, os termos da consulta expandida são colocados sob a forma de uma expressão booleana. Por exemplo, se os termos da consulta original são acidente e fatal, após a verificação da presença de conceitos equivalentes na ontologia, a sua forma expandida pode ser acidente, batida e colisão para o termo acidente, e fatal e morte para o termo fatal. A seguir, apresenta-se a expressão booleana da consulta, resultante do processo de expansão: (acidente or batida or colisão) and (fatal or morte). A expressão booleana é executada sobre uma base de dados estruturada, utilizando a linguagem SQL [107]. Uma vez que este banco de dados integrado pode armazenar documentos de diversas áreas do conhecimento, abrangendo uma grande variedade de assuntos e interesses, a lista de documentos recuperados pode conter diversos documentos que não são de interesse do usuário. Assim, o próximo passo é identificar o grau de similaridade de cada documento recuperado com relação à consulta fornecida por um usuário, dentro de um contexto

80 4.3 Recuperação de Documentos 79 especificado por uma ontologia, permitindo a construção de um ranking por ordem de relevância. Cálculo de Similaridade Existem várias técnicas para se estabelecer medidas ou coeficientes de similaridade entre documentos. A maioria destas medidas utiliza a comparação entre vetores de termos que representam os seus conteúdos. Na metodologia utilizada neste trabalho, a consulta e os documentos são representados através de vetores de características, contendo apenas os termos que são relevantes para o processo de contextualização destes documentos. Nos experimentos iniciais, o cálculo de similaridade foi realizado utilizando o cálculo do cosseno do ângulo formado pelos vetores que representam os objetos, conforme apresentado na Fórmula 2-2. Neste caso, utilizou-se o TF-IDF como métrica para a definição do peso de cada termo dos vetores dos documentos. No entanto, os resultados foram insatisfatórios, devido à dificuldade de ponderação do vetor da consulta. Dessa forma, para realizar o cálculo de similaridade entre a consulta e os documentos recuperados, decidiu-se utilizar o coeficiente de Jaccard [67], cuja fórmula é a seguinte: Jaccard = a (a + b) c, (4-1) onde, a representa o número de termos do vetor da consulta, b representa o número de termos do vetor de um determinado documento recuperado e c representa o número de termos comuns entre os dois vetores. Na Figura 4.10, apresenta-se o processo de seleção dos termos dos vetores de características, onde a Wikipédia (ou qualquer outro ambiente wiki implementado pelo software MediaWiki) é utilizada como um repositório de conhecimento auxiliar para a extração de termos relevantes, de acordo com um domínio de conhecimento especificado por uma ontologia. Conforme apresentado na Figura 4.10, os termos dos vetores de características são selecionados da seguinte forma: Para cada termo da consulta, verifica-se a sua presença na ontologia que especifica o domínio de conhecimento (conforme apresentado na Figura 4.8), obtendo a anotação que faz a ligação com os artigos de ambientes wiki implementados pelo software MediaWiki (como por exemplo, a Wikipédia) que definem este conceito. Caso esta ligação exista, o conteúdo dos artigos que se referem a este conceito são recuperados, através da manipulação da API do software MediaWiki.

81 4.4 Implementação de Web Services 80 Os conteúdos dos artigos recuperados são analisados e os termos mais frequentes são extraídos. Os termos extraídos são confrontados com a ontologia que especifica o domínio de conhecimento. A seguir, os termos do artigo que não estejam relacionados com o domínio de conhecimento em questão são excluídos. Finalmente, o vetor de característica é formado pela composição dos termos da consulta expandida, com a adição de outros termos retirados de ambientes wiki implementados pelo software MediaWiki, selecionados com o apoio de uma ontologia. Figura 4.10: Processo de seleção dos termos dos vetores de características Após a seleção dos termos que compõe os vetores de características, é calculado o valor do Coefiente de Jaccard entre o vetor da consulta e o vetor de cada documento recuperado. Este cálculo retorna um valor numérico no intervalo [0, 1], que indica o grau de similaridade entre estes dois vetores. 4.4 Implementação de Web Services Um web service é um sistema de software identificado através de um URI (Uniform Resource Identifier), no qual interfaces públicas e contratos são definidos e descritos em XML. Estas definições podem ser descobertas por outros sistemas de soft-

82 4.4 Implementação de Web Services 81 ware, que podem interagir com o web service de uma maneira prescrita pela sua definição, usando mensagens baseadas em XML e transportadas por protocolos da Internet [169]. Os serviços são descritos utilizando a linguagem WSDL (Web Services Description Language), que abrange todos os detalhes necessários para que se possa interagir com o serviço. A interface esconde os detalhes da execução do serviço, permitindo que seja utilizado independentemente da plataforma de hardware ou software em que esteja implementado e da linguagem de programação que foi escrito. Estas características fazem com que as aplicações baseadas em web services sejam fracamente acopladas e orientadas a serviços, facilitando o uso de vários serviços em conjunto para a execução de operações complexas. Os web services são componentes de software que são chamados a partir de outros aplicativos. As bases para a sua construção são os padrões XML e SOAP (Simple Object Access Protocol). O transporte dos dados é realizado via protocolo HTTP, onde os dados são transferidos no formato XML, encapsulados pelo protocolo SOAP. As respostas das requisições são retornadas no formato XML. Assim, todos os dados são rotulados através de etiquetas (tags), fazendo com que estes dados tenham consistência, permitindo que a troca de dados seja mais robusta. Para possibilitar a disponibilização de seus serviços, os web services necessitam estar ativos e aguardando por requisições. Neste trabalho, foi utilizado o Apache Tomcat [7] como um servidor de aplicações Java para a web, executando o Apache Axis [5] como framework de web services. No restante desta seção, apresenta-se a descrição das principais ações implementadas através de uma interface via web services, referentes ao processo de recuperação de informação do banco de dados integrado. Dessa forma, qualquer plataforma que interprete rotinas HTTP e manipule XML pode utilizar os serviços disponibilizados pelo web service do sistema desenvolvido neste trabalho. Conforme apresentado a seguir, foram disponibilizadas seis ações através da implementação de uma interface via web services. São elas: ListarRepositorios, ListarOntologias, Buscar, ObterRepositorio, ObterOntologia e ObterRegistro. Para cada ação, apresenta-se uma ou mais requisições. No Apêndice B, são apresentados trechos das respectivas respostas codificadas em XML ListarRepositorios Esta ação é utilizada para recuperar informações sobre os de provedores de dados cujos metadados foram coletados, pré-processados e disponibilizados para a realização de consultas. Argumentos

83 4.4 Implementação de Web Services 82 Nenhum Erros e Condições de Exceção erroargumentos: a requisição contêm argumentos que são ilegais; listavazia: a requisição não retornou nenhum registro. Formato de Resposta A resposta da requisição da ação ListarRepositorios retorna múltiplas instâncias do seguinte registro codificado em XML: id: o identificador local do provedor de dados; titulo: o título do provedor de dados; titulo_resumo: o título resumido do provedor de dados; url_repositorio: o URL do provedor de dados; url_harvester: o URL base para a coleta de metadados do provedor de dados. Exemplo de Requisição Requisição 1 Recupera informações sobre os provedores de dados disponíveis. Um trecho da resposta em XML é apresentado pelo Código B.1, no Apêndice B. acao=listarrepositorios ListarOntologias Esta ação é utilizada para recuperar informações sobre as ontologias disponibilizadas, que são utilizadas como mecanismos de especificação de domínios de conhecimento. Argumentos Nenhum Erros e Condições de Exceção erroargumentos: a requisição contêm argumentos que são ilegais; listavazia: a requisição não retornou nenhum registro. Formato de Resposta A resposta da requisição da ação ListarOntologias retorna múltiplas instâncias do seguinte registro codificado em XML:

84 4.4 Implementação de Web Services 83 id: o identificador local da ontologia; dominio: o domínio de conhecimento da ontologia; URIOnto: o URI da ontologia; fileonto: o endereço físico da ontologia; descricao: a descrição da ontologia. Exemplo de Requisição Requisição 2 Recupera informações sobre as ontologias disponibilizadas. Um trecho da resposta em XML é apresentado pelo Código B.2, no Apêndice B. acao=listarontologias Buscar Esta ação é utilizada para realizar a busca de documentos no banco de dados integrado. Argumentos consulta: é um argumento obrigatório, responsável pela especificação dos termos da consulta fornecidos por um determinado usuário; URIOnto: é um argumento obrigatório, responsável pela especificação do URI da ontologia; fileonto: é um argumento obrigatório, responsável pela especificação do endereço físico da ontologia; idrepositorio: é um argumento opcional, responsável pela especificação de um determinado provedor de dados no qual a consulta dever ser realizada. Quando este argumento é omitido, a consulta é realizada em todos provedores de dados disponibilizados. Erros e Condições de Exceção erroargumentos: a requisição contêm argumentos que são ilegais ou estão faltando argumentos obrigatórios; listavazia: a requisição não retornou nenhum registro; erroontologia: a ontologia não foi encontrada; erroidrepositorio: o valor do argumento idrepositorio é desconhecido ou ilegal. Formato de Resposta

85 4.4 Implementação de Web Services 84 A resposta da requisição da ação Buscar retorna uma instância do seguinte registro codificado em XML: qtderegitros: a quantidade de registros retornados pela consulta. A resposta da requisição da ação Buscar retorna múltiplas instâncias do seguinte registro codificado em XML: id: o identificador local do documento; valor: o valor de similaridade entre a consulta e o documento, calculado através do Coeficiente de Jaccard; qtdetotaltermos: a quantidade total de termos encontrado nos metadados do documento (incluindo repetições). Exemplo de Requisição Requisição 3 Realiza uma busca em todos os repositórios do banco de dados integrado, através da consulta leis de trânsito. Conforme informado nos argumentos URIOnto e fileonto que definem uma ontologia de domínio, esta busca está relacionada ao domínio de conhecimento trânsito. Um trecho da resposta em XML é apresentado pelo Código B.3, no Apêndice B. acao=buscar&consulta=leis%20de%20trânsito&urionto= semanticweb.org/ontologies/2009/7/mestrado_transito.owl& fileonto=d:/projetosjava/mestrado/mestrado_transito.owl Requisição 4 Realiza uma busca apenas no repositório identificado por um código local (idrepositorio=7) do banco de dados integrado, através da consulta leis de trânsito. Conforme informado nos argumentos URIOnto e fileonto que definem uma ontologia de domínio, esta busca está relacionada ao domínio de conhecimento trânsito. Um trecho da resposta em XML é apresentado pelo Código B.4, no Apêndice B. acao=buscar&consulta=leis%20de%20trânsito&urionto= semanticweb.org/ontologies/2009/7/mestrado_transito.owl& fileonto=d:/projetosjava/mestrado/mestrado_transito.owl& idrepositorio= ObterRepositorio Esta ação é utilizada para recuperar informações de um determinado repositório disponibilizado pelo sistema desenvolvido.

86 4.4 Implementação de Web Services 85 Argumentos id: é um argumento obrigatório, responsável pela especificação do identificador local de um determinado repositório. Erros e Condições de Exceção erroargumentos: a requisição contêm argumentos que são ilegais ou estão faltando argumentos obrigatórios; erroidrepositorio: o valor do argumento id é desconhecido ou ilegal. Formato de Resposta A resposta da requisição da ação ObterRepositorio retorna uma instância do seguinte registro codificado em XML: id: o identificador local do provedor de dados; titulo: o título do provedor de dados; titulo_resumo: o título resumido do provedor de dados; url_repositorio: o URL do provedor de dados; url_harvester: o URL base para a coleta de metadados do provedor de dados. Exemplo de Requisição Requisição 5 Recuperar informações de uma determinado repositório (id=7). A resposta em XML é apresentada pelo Código B.5, no Apêndice B. acao=obterrepositorio&id= ObterOntologia Esta ação é utilizada para recuperar informações de uma determinada ontologia. Argumentos id: é um argumento obrigatório, responsável pela especificação do identificador local de uma determinada ontologia. Erros e Condições de Exceção

87 4.4 Implementação de Web Services 86 erroargumentos: a requisição contêm argumentos que são ilegais ou estão faltando argumentos obrigatórios; erroidontologia: o valor do argumento id é desconhecido ou ilegal. Formato de Resposta A resposta da requisição da ação ObterOntologia retorna uma instância do seguinte registro codificado em XML: id: o identificador local da ontologia; dominio: o domínio de conhecimento da ontologia; URIOnto: o URI da ontologia; fileonto: o endereço físico da ontologia; descricao: a descrição da ontologia. Exemplo de Requisição Requisição 6 Recuperar informações de uma determinada ontologia (id=2). A resposta em XML é apresentada pelo Código B.6, no Apêndice B. acao=obterontologia&id= ObterRegistro Esta ação é utilizada para recuperar os metadados de um determinado documento do banco de dados integrado. Argumentos id: é um argumento obrigatório, responsável pela especificação do identificador local de um determinado documento. Erros e Condições de Exceção erroargumentos: a requisição contêm argumentos que são ilegais ou estão faltando argumentos obrigatórios; erroidregistro: o valor do argumento id é desconhecido ou ilegal. Formato de Resposta

88 4.5 Implementação da Interface de Busca 87 A resposta da requisição da ação ObterRegistro retorna uma instância do seguinte registro codificado em XML: id: o identificador local do documento; titulorep: o nome do provedor de dados do documento; identificador: o identificador público do documento, informado pelo seu provedor de dados. A resposta da requisição da ação ObterRegistro retorna uma instância do seguinte registro codificado em XML, onde cada elemento é opcional e pode ser repetido: title: o título do documento; creator: o criador do documento; date: a data do documento; language: a linguagem do conteúdo do documento; subject: o tema do documento; description: a descrição do conteúdo do documento; publisher: uma entidade responsável por tornar o documento acessível; identifier: o identificador público do documento; coverage: a extensão ou cobertura espaço-temporal do documento; type: a natureza ou gênero do conteúdo do documento; rights: as informações sobre direitos autorais do documento; contributor: uma entidade responsável por qualquer contribuição para o conteúdo do recurso; format: o formato do arquivo, meio físico ou as dimensões do recurso; source: uma referência a um recurso de onde o atual documento pode ter sido derivado; relation: uma referência a um recurso relacionado. Exemplo de Requisição Requisição 7 Recuperar os metadados de um determinado documento (id=10500) do banco de dados integrado. Um trecho da resposta em XML é apresentado pelo Código B.7, no Apêndice B. acao=obterregistro&id= Implementação da Interface de Busca Esta seção apresenta a interface de busca implementada para permitir a interação dos usuários com o módulo de recuperação de informação desenvolvido neste trabalho.

89 4.5 Implementação da Interface de Busca 88 Para a construção do núcleo do sistema desenvolvido, utilizou-se a linguagem de programação Java [106] para a implementação dos módulos responsáveis pelos processos de integração de provedores de dados e recuperação de informação. Conforme foi apresentado na Seção 4.4, algumas ações referentes ao processo de recuperação de informação no banco de dados integrado foram disponibilizadas através da implementação de uma interface via web services. Dessa forma, qualquer plataforma que interprete rotinas HTTP e manipule XML pode utilizar os serviços disponibilizados por este web service. A interface de busca foi desenvolvida utilizando a linguagem PHP (um acrônimo recursivo para PHP: Hypertext Preprocessor ) [155], o servidor web Apache [6], AJAX (Asynchronous Javascript And XML) [22] e os serviços disponibilizados pelo sistema desenvolvido (através de requisições via web services). PHP é uma linguagem de programação interpretada, livre e muito utilizada para gerar conteúdo dinâmico na web. Apache é um servidor de aplicações web, que permite a execução de aplicações desenvolvidas em PHP. AJAX é um modelo de programação que faz o uso sistemático de tecnologias oferecidas por navegadores, como JavaScript [49] e XML [36], para tornar as páginas mais interativas com os usuários, utilizando-se de requisições assíncronas. A Figura 4.11 apresenta a interface de busca disponibilizada para a recuperação de documentos do banco de dados integrado. Conforme pode ser observado nesta interface, um usuário pode informar os termos da consulta no campo Dados para a Busca. Em seguida, é necessário selecionar a ontologia que especifica o domínio de conhecimento, através do campo Domínio de Conhecimento e os repositórios no qual se deseja realizar a busca, através da caixa de seleção Repositórios. Por último, basta pressionar o botão Buscar no Repositório para realizar a busca de documentos no banco de dados integrado. Para a construção da interface de busca da Figura 4.11, foram realizadas algumas requisições via web services, que solicitam os seguintes serviços: ListarOntologias: esta requisição é utilizada para realizar a listagem das ontologias disponibilizadas pelo sistema desenvolvido, que especificam os domínios de conhecimento através do campo Domínio de Conhecimento. ListarRepositorios: esta requisição é utilizada para realizar a listagem dos repositórios disponibilizados pelo sistema desenvolvido, através da caixa de seleção Repositórios.

90 4.5 Implementação da Interface de Busca 89 Figura 4.11: Interface de busca para a recuperação de documentos do banco de dados integrado Analisando a Figura 4.11, observa-se que a busca refere-se aos termos colisão de trânsito, especificando o domínio de conhecimento Trânsito e considerando todos os repositórios disponibilizados. Na Figura 4.12, apresenta-se o resultado da busca referente aos dados preenchidos na Figura Conforme pode ser observado na Figura 4.12, o resultado de uma busca é uma lista ordenada decrescentemente pelo valor de similaridade de cada documento. O valor de similaridade é calculado pelo Coeficiente de Jaccard, que retorna um valor numérico no intervalo [0, 1], que indica o grau de similaridade da consulta fornecida pelo usuário e o documento recuperado, com relação ao domínio de conhecimento especificado por uma ontologia (quanto mais próximo de 1, maior é o grau de similaridade). Por exemplo, analisando a Figura 4.12, observa-se que o documento identificado pelo código 38789, com o valor de similaridade igual a 0.857, é o documento mais relevante identificado pelo sistema desenvolvido. Em seguida, tem-se o documento identificado pelo código , como valor de similaridade igual a

91 4.5 Implementação da Interface de Busca 90 Figura 4.12: Interface responsável pela listagem do resultado de uma busca Para a construção da interface da Figura 4.12, para cada documento recuperado é realizada uma requisição via web service solicitando o serviço ObterDocumento, utilizado para exibir os metadados de cada documento. Para cada documento apresentado na interface responsável pela listagem do resultado de uma busca, são apresentados apenas os metadados que especificam o repositório de origem, o título e parte da descrição do documento. Para visualizar todos os itens de metadados de um determinado documento, é necessário clicar no hiperlink Ver Detalhes, relativo a este documento. Na Figura 4.13, apresentam-se todos os itens de metadados referentes ao documento identificado pelo código

92 4.5 Implementação da Interface de Busca 91 Figura 4.13: Interface responsável pela visualização de todos os itens de metadados de um determinado documento Para a construção da interface da Figura 4.13, é realizada uma nova requisição via web service, solicitando o serviço ObterDocumento. Dessa forma, podem ser apresentados todos os itens de metadados de um determinado documento. Analisando a Figura 4.13, observa-se que é disponibilizado um hiperlink denominado Acessar Objeto, que permite o acesso do documento em seu repositório online de origem. Nesta interface, também é apresentada a quantidade total de termos encontrados nos metadados do documento (incluindo repetições), relativo ao domínio de conhecimento selecionado pelo usuário. A Figura 4.14 apresenta a interface responsável pela recuperação dos metadados de um determinado documento através de seu código. Conforme pode ser observado nesta interface, um usuário pode informar o código de um determinado objeto no campo Código do Objeto. Em seguida, basta pressionar o botão Recuperar pelo Código para recuperar os metadados deste documento. Para a construção da interface da Figura 4.14, é realizada uma requisição via web service, solicitando o serviço ObterDocumento. Dessa forma, como resultado desta requisição, são apresentados apenas os metadados que especificam o repositório de origem, o título e parte da descrição do documento. Para visualizar todos os itens de metadados deste documento, é necessário clicar no hiperlink Ver Detalhes.

93 4.5 Implementação da Interface de Busca 92 Figura 4.14: Interface responsável pela recuperação dos metadados de um documento através de seu código Figura 4.15: Interface responsável pela listagem de informações sobre todos os repositórios

94 4.5 Implementação da Interface de Busca 93 A Figura 4.15 apresenta a interface responsável pela listagem de informações sobre todos os repositórios disponibilizados. Para a construção desta interface, é realizada uma requisição via web service, solicitando o serviço ListarRepositorios. Na Figura 4.16, apresenta-se a interface responsável pela listagem de informações sobre todas as ontologias disponibilizadas. Figura 4.16: Interface responsável pela listagem de informações sobre todas as ontologias Para a construção da interface da Figura 4.16, é realizada uma requisição via web service, solicitando o serviço ListarOntologias.

95 Resultados CAPÍTULO 5 Este Capítulo apresenta os resultados obtidos, através da exposição de exemplos e análises de resultados, destacando a integração de provedores de dados e a recuperação contextualizada de documentos. Na Seção 5.1 são apresentados alguns dos provedores de dados com maior quantidade de metadados coletados no processo de integração. Na Seção 5.2 são apresentados alguns exemplos de consultas com relação a um determinado domínio de conhecimento que é especificado por uma ontologia. Em seguida, são apresentadas informações referentes aos resultados destas consultas e a análise das mesmas. 5.1 Integração de Provedores de Dados O processo de integração de provedores de dados foi realizado de acordo com o esquema apresentado na Figura 4.3. No restante desta seção, são apresentados alguns dos provedores de dados com maior quantidade de metadados coletados. Repositório Biblioteca Digital de Teses e Dissertações da USP URL Havester Qtde. de Registros Qtde. de Itens de Metadados Tabela 5.1: Quantidade de metadados coletados da Biblioteca Digital de Teses e Dissertações da USP

96 5.1 Integração de Provedores de Dados 95 Repositório Biblioteca Digital Jurídica do Superior Tribunal de Justiça URL Havester Qtde. de Registros Qtde. de Itens de Metadados Tabela 5.2: Quantidade de metadados coletados da Biblioteca Digital Jurídica do STJ Repositório Repositório Digital da UFRGS URL Havester Qtde. de Registros Qtde. de Itens de Metadados Tabela 5.3: Quantidade de metadados coletados do Repositório Digital da UFRGS Repositório Biblioteca Digital de Teses e Dissertações da UFPR URL Havester Qtde. de Registros Qtde. de Itens de Metadados Tabela 5.4: Quantidade de metadados coletados da Biblioteca Digital de Teses e Dissertações da UFPR Repositório Biblioteca Digital de Teses e Dissertações da UFRN URL Havester Qtde. de Registros Qtde. de Itens de Metadados Tabela 5.5: Quantidade de metadados coletados da Biblioteca Digital de Teses e Dissertações da UFRN

97 5.1 Integração de Provedores de Dados 96 Repositório Repositório Ação Educativa URL Havester Qtde. de Registros Qtde. de Itens de Metadados Tabela 5.6: Quantidade de metadados coletados do Repositório Ação Educativa Repositório Biblioteca Virtual sobre Corrupção URL Havester Qtde. de Registros Qtde. de Itens de Metadados Tabela 5.7: Quantidade de metadados coletados da Biblioteca Virtual sobre Corrupção Repositório Repositório Diálogo Científico URL Havester Qtde. de Registros Qtde. de Itens de Metadados Tabela 5.8: Quantidade de metadados coletados do Repositório Diálogo Científico Repositório Repositório Institucional da UnB URL Havester Qtde. de Registros Qtde. de Itens de Metadados Tabela 5.9: Quantidade de metadados coletados do Repositório Institucional da UnB

98 5.1 Integração de Provedores de Dados 97 Repositório Repositório local de dados não-estruturados URL Havester Qtde. de Registros Qtde. de Itens de Metadados Tabela 5.10: Quantidade de metadados coletados do Repositório local de dados não-estruturados O processo de coleta de metadados totalizou a quantidade de registros (documentos coletados dos repositórios) e itens de metadados (um documento possui vários campos de metadados que o descrevem, como por exemplo, título, autor, data, etc). Conforme discutido neste trabalho, as possibilidades de integração de dados utilizando o protocolo OAI-PMH não se limitam a estes tipos de provedores de dados. Para qualquer provedor de dados, pode-se utilizar ferramentas que permitam a exposição de seus metadados, possibilitando a utilização do protocolo OAI-PMH para a realização de requisições neste mesmo provedor. Figura 5.1: Diretório de dados não-estruturados Para permitir a exposição (através do protocolo OAI-PMH) do conteúdo de diretórios de dados não-estruturados (através de seus documentos no formato de texto plano), foi realizada uma adaptação da ferramenta phpoai2. Dessa forma, o conteúdo destes diretórios podem ser integrados ao banco de dados do sistema desenvolvido, da

99 5.1 Integração de Provedores de Dados 98 mesma forma que é realizado nas bibliotecas digitais ou qualquer outro provedor de dados que implemente o protocolo OAI-PMH. Como exemplo, nas Figuras 5.1 e 5.2, apresenta-se a exposição do conteúdo de um diretório de dados não-estruturados, que é organizado de acordo com o esquema da Figura 4.2. Conforme pode ser observado na Figura 5.1, existe um diretório raiz (docs), contendo vários sub-diretórios (Automobilismo, Carro, Ecologia, Informática, Trânsito, etc). Cada sub-diretório faz referência a um determinado assunto. Ainda analisando a Figura 5.1, observa-se que o conteúdo do sub-diretório Trânsito é uma listagem de vários arquivos no formato de texto plano. Na Figura 5.2, apresenta-se a exposição do conteúdo deste sub-diretório por meio do protocolo OAI-PMH, através de uma adaptação da ferramenta phpoai2. Figura 5.2: Exposição do conteúdo de um diretório de dados nãoestruturados através do protocolo OAI-PMH Conforme pode ser observado na Figura 5.2, através da utilização de ferramentas que possibilitam a abertura de metadados em conformidade com a OAI, torna-se possível o envio de requisições do protocolo OAI-PMH a provedores de dados pouco convencionais na implementação deste protocolo.

100 5.2 Recuperação de Documentos Recuperação de Documentos O desenvolvimento do módulo de recuperação de documentos têm como objeto a recuperação contextualizada de documentos em um banco de dados integrado através do protocolo OAI-PMH, contendo informações de diversos provedores de dados, como por exemplo, bibliotecas digitais, repositórios de dados não-estruturados, etc. Neste processo, são utilizadas ontologias como mecanismos de especificação de domínios e a análise de artigos de ambientes wiki. Os ambientes wiki são utilizados como repositórios de conhecimentos auxiliar para a extração de termos relevantes com relação à consulta e a uma ontologia que especifica um determinado domínio de conhecimento. Uma vez que uma ontologia esteja disponível, os metadados de diversos provedores de dados já tenham sido coletados, armazenados em uma base de dados estruturada e submetidos ao processo de pré-processamento, as consultas podem ser realizadas Exemplos de Consultas e Análise de Resultados Nesta seção, são apresentados alguns exemplos de consultas com relação a um determinado domínio de conhecimento. Para cada consulta, são apresentados os termos da consulta, o domínio de conhecimento da consulta, os termos da expansão da consulta, os artigos de ambiente wiki que foram analisados para a seleção de termos (relevantes à consulta e o domínio de conhecimento) e os termos relevantes selecionados. Os vetores de termos que compõe a consulta e cada documento são construídos a partir dos termos extraído de ambientes wiki, através do apoio de uma ontologia. A seguir, em todos os exemplos de consultas, os termos relevantes selecionados que são equivalentes a outros termos, são apresentados entre parênteses. Como exemplo, na Tabela 5.11 é apresentado o vetor de termos de um determinado documento que foi recuperado a partir de uma consulta relacionada aos termos Leis de Trânsito, considerando o domínio de conhecimento Trânsito. Conforme pode ser observado na Figura 5.11, o vetor de termo deste documento é composto por termos relevantes com relação à consulta e ao domínio de conhecimento, o stemming de cada termo e a quantidade de ocorrência de cada termo no documento, considerando as relações de equivalências que são definidas em uma ontologia.

101 5.2 Recuperação de Documentos 100 Termos Stemming Qtde de Ocorrências trânsito (tráfego) transit (trafeg) 8 veículos veicul 5 leis (normas, legislação) lei (norm, legisl) 3 código (ctb) codig (ctb) 1 infrações (crimes) infr (crim) 3 penalidades penal 1 dirigir dirig 2 tribunal tribun 0 motoristas (condutor) motor (condu) 2 pedestres pedestr 1 estrada estr 0 ruas rua 2 transportes transport 1 colisões (acidentes) colis (acid) 5 Tabela 5.11: Exemplo de um vetor de termos referente a um documento Na Tabela 5.12 são apresentadas algumas informações sobre uma consulta referente aos termos Leis de Trânsito, considerando o domínio de conhecimento Trânsito. Consulta Leis de Trânsito Domínio de Conhecimento Trânsito Expansão da Consulta lei, legislação, trânsito, tráfego Artigos Analisados Seleção de Termos trânsito (tráfego), veículos, leis (normas, legislação), código (ctb), infrações (crimes), penalidades, dirigir, tribunal, motoristas (condutor), pedestres, estrada, ruas, transportes, colisões (acidentes) Tabela 5.12: Consulta sobre Leis de Trânsito, considerando o domínio de conhecimento Trânsito

102 5.2 Recuperação de Documentos 101 A Figura 5.3 apresenta a distribuição da quantidade de documentos recuperados pela consulta da Tabela 5.12, de acordo com o intervalo referente aos valores de similaridade dos documentos, com relação à consulta e um domínio de conhecimento. No total, foram recuperados 74 documentos. Figura 5.3: Quantidade de documentos recuperados pela consulta Leis de Trânsito, considerando o domínio de conhecimento Trânsito O resultado do processo de recuperação de informação é um ranking de documentos, ordenado por maior grau de relevância com relação à consulta e a um domínio de conhecimento especificado por uma ontologia. Dessa forma, estabelecendo-se um limiar (que pode ser definido pelo usuário da aplicação) com relação ao valor de similaridade que originou o ranking de documentos, obtém-se a separação entre os possíveis documentos relevantes, os documentos considerados de pouca relevância e os documentos irrelevantes. Como exemplo, estabelecendo-se o limiar como sendo o valor maior o igual a 0.4 para o resultado da consulta apresentada na Figura 5.3, a sub-lista composta pelos 14 primeiros documentos deverão ser considerados mais relevantes com relação a lista total de 74 documentos. Analisando o resultado da Figura 5.3, observa-se que apenas 1 documento contido na sub-lista de 14 documentos mais relevantes não é um documento relevante. Ainda, 2 documentos com pouca relevância com relação à consulta e ao domínio de conhecimento (identificado pela ferramenta desenvolvida com um grau de similaridade inferior a 0.4) não foram relacionados na sub-lista de 14 documentos mais relevantes. Na Tabela 5.13 são apresentas algumas informações sobre uma consulta referente aos termos Colisão de Trânsito, considerando o domínio de conhecimento Trânsito.

103 5.2 Recuperação de Documentos 102 Consulta Colisão de Trânsito Domínio de Conhecimento Trânsito Expansão da Consulta colisão, acidente, trânsito, tráfego Artigos Analisados Seleção de Termos colisão (acidente), motoristas (condutor), trânsito (tráfego), transportes, atropelamento, automóvel (carro), feridos, pedestres, estrada, código (ctb), ruas Tabela 5.13: Consulta sobre Colisão de Trânsito, considerando o domínio de conhecimento Trânsito A Figura 5.4 apresenta a distribuição da quantidade de documentos recuperados pela consulta da Tabela 5.13, de acordo com o intervalo referente aos valores de similaridade dos documentos, com relação à consulta e um domínio de conhecimento. No total, foram recuperados 65 documentos. Figura 5.4: Quantidade de documentos recuperados pela consulta Colisão de Trânsito, considerando o domínio de conhecimento Trânsito Na Tabela 5.13 são apresentas algumas informações sobre uma consulta referente aos termos Colisão de Trânsito, considerando o domínio de conhecimento Sistemas Distribuídos.

104 5.2 Recuperação de Documentos 103 Consulta Colisão de Trânsito Domínio de Conhecimento Sistemas Distribuídos Expansão da Consulta colisão, falha, trânsito, tráfego, transmissão Artigos Analisados computadores_e_tecnologias_de_rede/redes_de_computadores Seleção de Termos colisão (falha), computadores, usuário, distribuídos, rede, hardware, comunicação, arquitetura, tráfego (trânsito, transmissão), topologia, telecomunicações Tabela 5.14: Consulta sobre Colisão de Trânsito, considerando o domínio de conhecimento Sistemas Distribuídos A Figura 5.5 apresenta a distribuição da quantidade de documentos recuperados pela consulta da Tabela 5.14, de acordo com o intervalo referente aos valores de similaridade dos documentos, com relação à consulta e um domínio de conhecimento. No total, foram recuperados 52 documentos. Figura 5.5: Quantidade de documentos recuperados pela consulta Colisão de Trânsito, considerando o domínio de conhecimento Sistemas Distribuídos Com relação aos resultados apresentados pelo sistema desenvolvido, foi observado que alguns documentos recuperados, apesar de possuírem alguma relevância com

105 5.2 Recuperação de Documentos 104 relação aos termos da consulta e ao domínio de conhecimento especificado nesta consulta, tiveram um baixo valor de similaridade. Analisando esse fato, chegou-se a conclusão de que este comportamento é motivado principalmente pela qualidade dos metadados destes documentos, uma vez que estão mal preenchidos ou com descrições bastante resumidas. Dessa forma, fica evidenciado que a qualidade dos metadados é um fator muito importante para a recuperação e contextualização de documentos. Por outro lado, também foi observado que os documentos que não possuem relevância com relação à consulta e ao domínio de conhecimento especificado nesta consulta e que tiveram um alto valor de similaridade é motivado pelo fato destes documentos possuírem muitos termos em comum com o domínio de conhecimento especificado na consulta. Como alternativa para evidenciar o comportamento do ranking de documentos, alguns documentos significativamente representativos com relação a domínios de conhecimentos pré-estabelecidos foram integrados ao sistema desenvolvido, com a finalidade de serem monitorados. Este monitoramento se resume na análise do posicionamento destes documentos, considerando o domínio de conhecimento ao qual pertencem. Estes documentos foram integrados ao banco de dados a partir do diretório de dados nãoestruturados, conforme apresentado nas Figuras 5.1 e 5.2. Os documentos selecionados pertencem aos domínios de Trânsito ou Sistemas Distribuídos. Figura 5.6: (A) Trecho dos documentos monitorados do domínio de Trânsito (B) Trecho dos documentos monitorados do domínio de Sistemas Distribuídos Os documentos de domínios conhecidos foram selecionados a partir de sites de busca tradicionais e coletados de suas respectivas páginas da Internet. O único critério para a seleção destes documentos foi que os mesmos pertencessem a um dos domínios de conhecimento pré-estabelecidos e que cada documento tivesse alguns termos em comum aos dois domínios de conhecimentos, de forma suficiente para que todos os documentos

106 5.2 Recuperação de Documentos 105 monitorados fossem recuperados em consultas considerando os dois domínios. Na Figura 5.6, apresenta-se um trecho de cada documento utilizado para o monitoramento. A Figura 5.7 apresenta a distribuição das posições de todos os documentos monitorados com relação ao ranking composto por 65 documentos, para a consulta Colisão de Trânsito, considerando o domínio de conhecimento Trânsito. Figura 5.7: Distribuição das posições de todos os documentos monitorados, para a consulta Colisão de Trânsito, considerando o domínio de conhecimento Trânsito Conforme pode ser observado na Figura 5.7, todos os documentos monitorados que realmente pertencem ao domínio de conhecimento Trânsito foram distribuídos entre as primeiras posições do ranking de documentos. Por outro lado, todos os documentos monitorados que não fazem parte do domínio de conhecimento Trânsito foram distribuídos em posições distantes das iniciais. Na Figura 5.8, apresenta-se a distribuição das posições de todos os documentos monitorados com relação ao ranking composto por 52 documentos, para a consulta Colisão de Trânsito, considerando o domínio de conhecimento Sistemas Distribuídos.

107 5.2 Recuperação de Documentos 106 Figura 5.8: Distribuição das posições de todos os documentos monitorados, para a consulta Colisão de Trânsito, considerando o domínio de conhecimento Sistemas Distribuídos Conforme pode ser observado na Figura 5.8, todos os documentos monitorados que realmente se referem ao domínio de conhecimento Sistemas Distribuídos foram distribuídos entre as primeiras posições do ranking de documentos. Por outro lado, todos os documentos monitorados que não fazem parte do domínio de conhecimento Sistemas Distribuídos foram distribuídos em posições distantes das iniciais. Todos os documentos monitorados foram recuperados e utilizados para a construção dos gráficos das Figuras 5.4 e 5.5. Analisando os gráficos das Figuras 5.4 e 5.5, e também das Figuras 5.7 e 5.8, é possível visualizar o comportamento do ranking de documentos, com relação à distribuição de alguns documentos neste ranking e o valor de similaridade com relação à consulta e o domínio de conhecimento. Os experimentos das Figuras 5.7 e 5.8, mostram que em situações ideais é possível obter uma importante separação entre os documentos relevantes e irrelevantes, com relação à consulta e um domínio de conhecimento. Observando o caso geral, conforme apresentado nos resultados das Figuras 5.3, 5.4 e 5.5, observa-se que esta situação também é satisfatória. Neste trabalho, entende-se como ideais, situações em que os documentos são

108 5.2 Recuperação de Documentos 107 bem representativos com relação ao seu real domínio de conhecimento (ou seja, seus metadados são bem preenchidos), o domínio de conhecimento é bem representado através de uma ontologia de qualidade, os artigos de ambientes wiki que apoiam o processo de seleção de termos para a construção dos vetores de termos que caracterizam a consulta e os documentos são de fato relevantes e representativos com relação à consulta e o domínio de conhecimento.

109 Conclusões CAPÍTULO 6 As bibliotecas digitais estão se tornando amplamente aceitas como fontes de divulgação de informação em diversas áreas do conhecimento. Elas têm se constituído como um importante instrumento para a disponibilização da informação, permitindo o acesso ao conhecimento de qualquer lugar onde exista um computador conectado à Internet. Estes repositórios são desenvolvidos com diferentes arquiteturas e tecnologias, são gerenciados por organizações distintas, submetidos a diferentes padrões de qualidade, etc. Este ambiente distribuído e heterogêneo introduz um alto grau de complexidade na conquista de uma visão integrada das coleções digitais. Entre os vários motivos que tornam o protocolo OAI-PMH como um dos principais protocolos para a interoperabilidade entre os repositórios digitais, destaca-se a sua simplicidade de implementação, arquitetura de baixo custo e a existência de ferramentas open source para a implementação de repositório digitais que possuem uma interface com este protocolo. O protocolo OAI-PMH é baseado no HTTP e XML, permitindo uma fácil manipulação. Os metadados compartilhados pelos repositórios podem estar em qualquer padrão previamente definido por uma comunidade. No entanto, o protocolo OAI-PMH especifica a utilização do padrão Dublin Core para fornecer um nível básico de interoperabilidade. No Brasil, o IBICT é o principal incentivador da adoção do modelo Open Archives pelas instituições brasileiras. Esse apoio possibilita a multiplicação dos repositórios nacionais de informação científica, permitindo que informações de grande relevância sejam compartilhadas com pesquisadores de todo mundo. Neste trabalho, foi constatado de forma experimental que o protocolo OAI-PMH é um mecanismo eficiente para a integração de repositórios digitais. No entanto, as possibilidades de integração de dados utilizando este protocolo não se limitam aos repositórios tradicionais (como por exemplo, as bibliotecas digitais). A utilização de ferramentas que possibilitam a implementação de provedores de dados podem ser utilizadas para expor da-

110 6.1 Contribuições 109 dos ou metadados de qualquer fonte de informação, como por exemplo, bancos de dados distribuídos, diretórios de arquivos não-estruturados, etc. Os ambientes wiki foram utilizados como repositórios de conhecimento auxiliar, manipulados através do conhecimento mapeado em uma ontologia. Uma vez que o processo de construção de ontologias é bastante oneroso, a utilização de ambientes wiki mostrou-se útil na identificação de conceitos relacionados aos termos que são fornecidos em consultas pelos usuários. Dessa forma, diversos conceitos e relacionamentos entre estes conceitos que podem não estar presentes na ontologia que especifica o domínio de conhecimento podem ser extraídos destes ambientes, sendo úteis na recuperação contextualizada dos documentos. Este fato pode ser evidenciado conforme os exemplos apresentados, onde o vetor de termo resultante após a consulta em ambientes wiki é enriquecido com termos que realmente se referem à consulta e o domínio de conhecimento em questão. O resultado do processamento do sistema desenvolvido é um ranking de documentos ordenado por maior grau de relevância com relação à consulta e a um determinado domínio de conhecimento, que é especificado por uma ontologia. Dessa forma, estabelecendo-se um limiar (que pode ser definido pelo usuário da aplicação), com relação ao valor de similaridade que originou este ranking, obtém-se a separação entre os documentos relevantes e irrelevantes, com relação à consulta e a um domínio de conhecimento, de acordo com o processamento do sistema desenvolvido. No contexto deste trabalho, o principal problema na contextualização de documentos está relacionado ao mal preenchimento dos metadados que são coletados dos provedores de dados. A qualidade dos metadados está relacionada ao seu preenchimento de forma completa e consistente. É recomendável o preenchimento de todos os itens de metadados, que devem ser preenchidos com informações relevantes, de uma forma bastante abrangente, respeitando a definição especificada por um determinado padrão de metadados. Por exemplo, para o padrão Dublin Core, os campos title e description devem conter, respectivamente, o título e o resumo de um determinado documento. A seguir, na Seção 6.1 são apresentadas as principais contribuições deste trabalho. Na Seção 6.2 são apresentados os artigos e relatórios técnicos produzidos durante o desenvolvimento desta dissertação. Finalmente, na Seção 6.3 são apresentados os trabalhos futuros. 6.1 Contribuições Nesta Seção, apresenta-se um resumo das principais contribuições identificadas durante o desenvolvimento desta dissertação.

111 6.1 Contribuições 110 Desenvolvimento da Ferramenta: A principal contribuição desta dissertação é o desenvolvimento e implementação de uma metodologia para a recuperação contextualizada de documentos em um conjunto de bibliotecas digitais, repositórios e outros provedores de dados, integrados por meio do protocolo OAI-PMH. Integração de Provedores de Dados: O OAI-PMH é um protocolo bastante utilizado para a coleta de metadados em bibliotecas digitais e outros provedores de dados tradicionais. Neste trabalho, mostrou-se que o protocolo OAI-PMH pode ser utilizado para a integração de repositórios pouco convencionais na implementação deste protocolo (como por exemplo, diretórios de dados não-estruturados, etc), através da adaptação de ferramentas disponibilizadas pela comunidade Open Archives Initiative. Construção de um Ranking de Documentos: Com relação à ferramenta desenvolvida, foram apresentados exemplos e análises de resultados, mostrando o comportamento do ranking de documentos, ordenado por maior grau de relevância com relação à consulta e um domínio de conhecimento. A análise dos documentos monitorados (documentos conhecidos que pertencem significativamente a um determinado domínio de conhecimento pré-estabelecido), mostrou-se que os documentos que realmente referem-se ao domínio de conhecimento especificados na consulta foram alocados entre as primeiras posições do ranking de documentos. Por outro lado, todos os documentos monitorados que não fazem parte deste domínio de conhecimento foram alocados em posições distantes das iniciais. Ontologias e Aplicações Semânticas: Neste trabalho, as ontologias foram utilizadas como mecanismos de especificação de domínios de conhecimentos nos processos de expansão da consulta e contextualização de documentos, apresentando resultados satisfatórios. Dessa forma, pretende-se estimular o desenvolvimento, compartilhamento e a utilização de ontologias, bem como o desenvolvimento de novas aplicações com algum tipo de processamento semântico, como forma de contribuir para o desenvolvimento da Web Semântica. Ambientes wiki como Repositórios de Conhecimento Auxiliar: Neste trabalho, os ambientes wiki (implementados pelo software MediaWiki) foram utilizados como repositórios de conhecimento auxiliar, para a extração de termos relevantes com relação a uma consulta fornecida por um usuário e a um determinado domínio de conhecimento, que é especificado por uma ontologia. Dessa forma, diversas relações que podem não estar presentes na ontologia (uma vez que a construção de ontologias é um processo complexo) podem ser identificados. Estudo da API do MediaWiki: O MediaWiki é um pacote de software livre com uma rica implementação para o desenvolvimento de ambientes colaborativos. O MediaWiki foi originalmente escrito para a Wikipédia e tem sido utilizado

112 6.2 Produção Bibliográfica 111 por diversas organizações em todo o mundo. A API do MediaWiki disponibiliza uma grande quantidade de serviços. Conforme foi apresentado neste trabalho, os serviços disponibilizados pela API do MediaWiki podem ser facilmente acessados, possibilitando a recuperação de informações úteis com relação a todo o conteúdo disponibilizado por este software. Assim, pretende-se motivar a utilização da API do MediaWiki por aplicações externas, como alternativa para a exploração de todo o seu conteúdo colaborativo. Implementação de Web Services: Neste trabalho, foram disponibilizadas diversas funcionalidades referentes ao processo de recuperação de informação do banco de dados integrado, através da implementação de uma interface via web services. Dessa forma, o módulo para a recuperação contextualizada de documentos pode ser facilmente integrado a qualquer plataforma de software que interprete rotinas HTTP e manipule XML. Desenvolvimento de uma Interface Web: Para permitir a interação de usuários com o módulo de recuperação contextualizada de documentos, foi desenvolvida uma interface web. Todo o núcleo da ferramenta e a interface dos serviços disponibilizados via web services foram implementados utilizando a linguagem Java. No entanto, a interface web foi desenvolvida utilizando a linguagem PHP, onde toda a comunicação com o núcleo da ferramenta é realizado através dos serviços disponibilizados pela web service da ferramenta desenvolvida, através de requisições assíncronas com AJAX. 6.2 Produção Bibliográfica Nesta seção, apresenta-se os artigos publicados e os relatórios técnicos produzidos durante o desenvolvimento desta dissertação. Para cada artigo ou relatório técnico, apresenta-se o título em negrito, seguido pelos respectivos resumos extraídos dos originais (que permite identificar a relação destes com esta dissertação). Finalmente, para o caso dos artigos, é apresentado o evento no qual foi publicado. Artigos Publicados: Recuperação Contextualizada de Documentos em Bibliotecas Digitais Integradas [120]. Este trabalho aborda a recuperação contextualizada de documentos em um conjunto de Bibliotecas Digitais integradas por meio do protocolo OAI-PMH. Neste caso, apenas os documentos que fazem parte de um domínio especificado devem ser recuperados. No processo de contextualização das consultas, são utilizadas on-

113 6.2 Produção Bibliográfica 112 tologias e a análise do conteúdo dos artigos da Wikipédia (através da manipulação de sua API), a qual é utilizada como um repositório de conhecimento auxiliar. In: 8th International Information and Telecommunication Technologies Symposium, Florianópolis, Brazil. I2TS 2009, December 09-11, Contextualized Retrieval of Documents in Semantic Environments [125]. This paper addresses the contextualized retrieval of documents on a set of digital repositories and other data sources. The retrieved documents are integrated through the OAI-PMH protocol. Ontologies and analysis of documents, available in wiki environments, are used in the process of contextualization of queries. The developed prototype produces a ranking of documents, sorted by greater degree of importance with respect to the query. In: IADIS International Conference, e-society 2010, Porto, Portugal. IADIS e-society ES 2010, March 18-21, Contextual Retrieval of Documents in Integrated Data Providers [124]. The system described in this work addresses the integration of a set of digital libraries, repositories and other data providers, integrated through the OAI-PMH protocol. Subsequently, this integrated repository is used for contextualized documents recovery, considering the Portuguese language. The definition of contexts has been implemented using ontologies and content analysis of articles in wiki environments. The result presented by developed system is a ranking of documents ordered by a higher degree of importance with respect to the query provided by a user and a particular domain of knowledge, which is specified by an ontology. In: International Conference on Computational Processing of Portuguese Language, Porto Alegre, Brazil. Propor 2010, Demonstrations Session, April 27-30, Relatórios Técnicos: Bibliotecas Digitais e a solução Fedora (Flexible Extensible Digital Object Repository Architecture) [121]. Uma biblioteca digital é uma biblioteca em que seu acervo é armazenado em formato digital. As Bibliotecas Digitais são um conjunto de recursos eletrônicos e capacidades técnicas associadas para criar, buscar e usar informações. O Fedora é uma plataforma de código aberto que oferece uma arquitetura projetada para servir como base para a implementação de repositórios digitais para uma grande variedade de aplicações. Este trabalho tem como objetivo discutir alguns conceitos e características das Bibliotecas Digitais e apresentar a solução Fedora. Implementação de Interoperabilidade entre Repositórios Digitais por meio do Protocolo OAI-PMH [122]. O OAI-PMH (Open Archives Initiative - Protocol for Metadata Harvesting) é um protocolo que possibilita aos participantes da iniciativa Open Archives Initiative

114 6.3 Trabalhos Futuros 113 expor seus metadados para aplicações externas que desejem coletá-los. Este protocolo vem se consolidando como um mecanismo eficiente para a implementação de interoperabilidade entre bibliotecas e repositórios digitais. Este trabalho tem como objetivo apresentar e analisar o protocolo OAI-PMH de uma forma teórica e prática. Introdução aos Algoritmos de Agrupamento [123]. Os algoritmos de agrupamento têm sido estudados intensivamente por sua aplicabilidade em diversas áreas. Estes algoritmos criam conjuntos que possuem características semelhantes, com o objetivo de agrupar os atributos dos dados processados de acordo com sua similaridade. Dessa forma, objetos pertencentes a um mesmo grupo tendem a ser mais similares entre si, com relação a objetos pertencentes a outros grupos. Este trabalho tem como objetivo apresentar uma visão geral sobre os algoritmos de agrupamento, destacando sua importância como técnica de reconhecimento de padrões não-supervisionada. 6.3 Trabalhos Futuros A partir do levantamento bibliográfico e da ferramenta desenvolvida nesta dissertação, pode-se destacar os seguintes trabalhos futuros: Identificação das melhores práticas e elaboração de políticas efetivas para o preenchimento de metadados de forma completa e consistente, como forma de alcançar uma padronização e uma boa qualidade dos metadados disponibilizados pelos provedores de dados. Utilização de outras abordagens para o cálculo de similaridade. Por exemplo, a identificação de similaridade entre objetos utilizando a técnica de Análise Semântica Latente pode ser uma possibilidade promissora. Construção de ontologias por meio de processos semi-automatizados, através da utilização de ambientes colaborativos. Como exemplo de ambientes úteis para este propósito, cita-se os ambientes wiki e as Comunidades Virtuais de Prática (CoPs). Exploração do conteúdo de ambientes wiki semânticos, que combinam as tecnologias da Web Semântica com a tecnologia e os conceitos dos ambientes wiki tradicionais.

115 Referências Bibliográficas [1] ALEXANDER MAEDCHE, STEFFEN STAAB. Ontology Learning for the Semantic Web. Kluwer Academic Publishers, [2] AMAIA BERNARAS, IÑAKI LARESGOITI, JOSE CORERA. Building and Reusing Ontologies for Electrical Network Applications. Proceedings of the European Conference on Artificial Intelligence, ECAI/96, [3] ANDREAS LUDWIG, PETER BECKER, ULRICH GUNTZER. Interfacing online Bibliographic Databases with Z IDEAS 97: Proceedings of the 1997 International Symposium on Database Engineering & Applications, [4] ANDY POWELL, MICHAEL DAY, PETER CLIFF. Using simple Dublin Core to describe eprints. Disponível em acessado em janeiro de [5] Apache Axis. Disponível em acessado em janeiro de [6] Apache HTTP Server. Disponível em acessado em janeiro de [7] Apache Tomcat. Disponível em acessado em janeiro de [8] Archimèd Project Repository. Disponível em acessado em janeiro de [9] ARNO Repository. Disponível em acessado em janeiro de [10] ArXiv e-print Archive. Disponível em acessado em janeiro de [11] ASUNCIÓN GÓMEZ-PÉREZ, MARIANO FERNÁNDEZ-LÓPEZ, OSCAR CORCHO. Ontological Engineering: with examples from the areas of Knowledge Management, e-commerce and the Semantic Web. Springer Verlag, Madri, 2005.

116 Referências Bibliográficas 115 [12] Biblioteca Digital Brasileira de Teses e Dissertações. Disponível em acessado em janeiro de [13] Biblioteca Digital de Teses e Dissertações da UFPR. Disponível em acessado em janeiro de [14] BILL SWARTOUT, RAMESH PATIL, KEVIN KNIGHT, TOM RUSS. Toward Distributed Use of Large-Scale Ontologies. Banff Knowledge Aquisition Workshop, [15] Dicionário br.ispell. Disponível em ueda/br.ispell, acessado em janeiro de [16] CARLOS HENRIQUE MARCONDES, HÉLIO KURAMOTO, LÍDIA BRANDÃO TOUTAIN E LUÍS SAYÃO. Bibliotecas Digitais: Saberes e Práticas. Salvador/Brasilia: EDUFBA/IBICT, [17] CARLOS HENRIQUE MARCONDES, LUÍS FERNANDO SAYÃO. Integração e interoperabilidade no Acesso a Recursos Informacionais Eletrônicos em C&T: a Proposta da Biblioteca Digital Brasileira. Ci. Inf., Brasília, v. 30, n. 3, p , [18] CDSware CERN Document Server Software. Disponível em cern.ch, acessado em janeiro de [19] CiteSeer Scientific Literature Digital Library. Disponível em psu.edu, acessado em janeiro de [20] Clube OAI Brasil. Disponível em acessado em janeiro de [21] Cogprints Cognitive Science eprint Archive. Disponível em acessado em janeiro de [22] CRISTIAN DARIE, BOGDAN BRINZAREA, FILIP CHERECHES TOSA, MIHAI BUCICA. AJAX and PHP: Building Responsive Web Applications. Packt Publishing, [23] DAML DARPA Agent Markup Language. Disponível em acessado em janeiro de [24] DAML+OIL. Disponível em acessado em janeiro de [25] DANIELA LUCAS DA SILVA, RENATO ROCHA SOUZA, MAURÍCIO BARCELLOS AL- MEIDA. Ontologias e vocabulários controlados: comparação de metodologias para construção. Ci. Inf., Brasília, v. 37, n. 3, p , 2008.

117 Referências Bibliográficas 116 [26] DAVID BAINBRIDGE, GEORGE BUCHANAN, JOHN MCPHERSON, STEVE JONES, ABDELAZIZ MAHOUI, IAN H. WITTEN. Greenstone: A platform for distributed digital library applications. European Digital Library Conference, [27] DAVID PATRICIO VISCARRA DEL POZO. Modelagem e Prototipação de uma Biblioteca Digital Usando a Abordagem 5S. Dissertação de Mestrado, Instituto de Ciências Exatas, Universidade Federal de Minas Gerais, [28] DEAN ALLEMANG, JIM HENDLER. Semantic Web for the Working Ontologist Effective Modeling in RDFS and OWL. Morgan Kaufmann, [29] Dienst Protocol Specification. Disponível em dienst/protocols/dienstprotocol.htm, acessado em janeiro de [30] Digital Library Federation. Disponível em acessado em janeiro de [31] DSpace Digital Repository Software. Disponível em acessado em janeiro de [32] Dublin Core. Disponível em acessado em janeiro de [33] ECS EPrints Repository. Disponível em acessado em janeiro de [34] EDUARDO TOLEDO SANTOS, LUIZ ANTONIO DO NASCIMENTO. Recuperação de Informação em Sistemas de Informações na Construção Civil: O caso das EXTRANETS de Projeto. Seminário de Tecnologia de Informação e Comunicação na Construção Civil, Curitiba-PR, UFPR, [35] ELLEN M. VOORHEES. Query Expansion Using Lexical-Semantic Relations. Proceedings of the 17th annual international ACM SIGIR conference on Research and development in information retrieval, [36] ELLIOTTE RUSTY HAROLD. XML 1.1 Bible. 3rd Edition, Wiley Publishing, [37] Eprints Digital Repository Software. Disponível em acessado em janeiro de [38] EVELINE CRUZ HORA GOMES FERREIRA. Geração Automática de Metadados: uma Contribuição para a Web Semântica. Tese de Doutorado, Escola Politécnica da Universidade de São Paulo, USP, 2006.

118 Referências Bibliográficas 117 [39] EVELYN CRISTINA PINTO. Repensando os Commons na Comunicação Científica. Dissertação de Mestrado, Instituto de Matemática e Estatística, Universidade de São Paulo, [40] EVGENIY GABRILOVICH, SHAUL MARKOVITCH. Computing Semantic Relatedness using Wikipedia-based Explicit Semantic Analysis. International Joint Conference on Artificial Intelligence, [41] FABRÍCIO J. BARTH, ANTONIO PEDRO TIMOSZCZUK. Recuperação de informação contextualizada em portais do Governo Federal com base no conteúdo da Lista de Assuntos do Governo. XXIX Congresso da Sociedade Brasileira de Computação, [42] Fedora Commons Repository Software. Disponível em acessado em janeiro de [43] FEITOSA, A. Organização da Informação na Web: das Tags à Web Semântica. Editora Thesaurus, Brasília, [44] FRANKLIN RAMALHO, JACQUES ROBIN. Avaliação Empírica da Expansão de Consultas Baseada em um Thesaurus: Aplicação em um Engenho de Busca da Web. Revista de Informática Teórica e Aplicada - RITA, Volume 10, Número 2, [45] FURNAS G. W., DEERWESTER S., DUMAIS S. T.. Information Retrieval Using a Singular Value Decomposition Model of Latent Semantic Structure. Proceedings of the 11th annual international ACM SIGIR Conference on Research and Development in Information Retrieval, [46] G. H. GOLUB, C. REINSCH. Singular Value Decomposition and Least Squares Solutions. Numerische Mathematik, [47] GERARD SALTON, CHRIS BUCKLEY. Term-Weighting Approaches in Automatic Retrieval. Information Processing & Management, [48] Greenstone Digital Library Software. Disponível em acessado em janeiro de [49] HARVEY M. DEITEL. JavaScript for Programmers. Prentice Hall Professional, [50] HÉLIO KURAMOTO. IBICT estimula a Adoção dos Open Archives no Brasil. Instituto Brasileiro de Informação em Ciência e Tecnologia. Disponível em acessado em janeiro de 2010.

119 Referências Bibliográficas 118 [51] HUMBERTO MOSSRI DE ALMEIDA. Uma Abordagem de Componentes Combinados para a Geração de Funções de Ordenação usando Programação Genética. Dissertação de Mestrado, Instituto de Ciências Exatas, Universidade Federal de Minas Gerais, [52] HUSSEIN SULEMAN, EDWARD FOX. The Open Archives Initiative: Realizing Simple and Effective Digital Library Interoperability. Journal of Library Administration, [53] IBICT Instituto Brasileiro de Informação em Ciência e Tecnologia. Disponível em acessado em janeiro de [54] i-tor (Tools and technologies for Open Repositories). Disponível em i-tor.org/en/toon, acessado em janeiro de [55] JANE GREENBERG. Metadata and the World Wide Web. Encyclopedia of Library and Information Science, New York: Marcel Dekker, [56] Jazzy Java Spell Check API. Disponível em acessado em janeiro de [57] Jena A Semantic Web Framework for Java. Disponível em acessado em janeiro de [58] JOHN DOMINGUE. Tadzebao and WebOnto: Discussing, browsing, and editing ontologies on the web. In 11th Knowledge Acquisition for Knowledge-Based Systems Workshop, [59] JÚNIO CÉSAR DE LIMA. Uma Ferramenta baseada nas Tecnologias da Web Semântica para Gestão de Conhecimento em Comunidades Virtuais de Prática. Dissertação de Mestrado, Instituto de Informática, Universidade Federal de Goiás, [60] KARIN KOOGAN BREITMAN. Web Semântica: a Internet do Futuro. Editora LTC, Rio de Janeiro, [61] KATRINA HODGSON. Metadata: Foundations, Potential, and Applications. Disponível em acessado em janeiro de [62] Kepler Repository. Disponível em acessado em janeiro de 2010.

120 Referências Bibliográficas 119 [63] KOTARO NAKAYAMA, MINGHUA PEI, MAIKE ERDMANN, MASAHIRO ITO, MASUMI SHIRAKAWA, TAKAHIRO HARA AND SHOJIRO NISHIO. Wikipedia Mining Wikipedia as a Corpus for Knowledge Extraction. Proceedings of Annual Wikipedia Conference, [64] KOTARO NAKAYAMA, TAKAHIRO HARA, SHOJIRO NISHIO. Wikipedia Mining for an Association Web Thesaurus Construction. International Conference on Web Information Systems Engineering, [65] LANCASTER, F. W. Indexação e Resumos: Teoria e Prática. Briquet de Lemos Livros, Brasília, [66] LUCIENE CHAGAS DE OLIVEIRA. Meta-Modelo Funcional para Recuperação de Informação. Dissertação de Mestrado, Programa de Pós-Graduação em Ciência da Computação, Universidade Federal de Uberlândia, [67] MANNING C. D.. An Introduction to Information Retrieval. Cambridge University Press, Cambridge, England, [68] MARCIA ROSETTO, ADRIANA HYPÓLITO NOGUEIRA. Aplicação de Elementos Metadados Dublin Core para Descrição de Dados Bibliográficos on-line da Biblioteca Digital de Teses da USP. Seminário Nacional de Bibliotecas Universitárias, Recife, [69] MARCOS JOSÉ DE M. CARDOSO JUNIOR. Clio-i: Interoperabilidade entre Repositórios Digitais utilizando o protocolo OAI-PMH. Dissertação de Mestrado, Centro de Informática, Universidade Federal de Pernambuco, [70] MARI VALLEZ, RAFAEL PEDRAZA-JIMENEZ. Natural Language Processing in Textual Information Retrieval and Related Topics. Hipertext.net, [71] MARIA DE LOURDES DA SILVEIRA. Recuperação Vertical de Informação: Um Estudo de Caso na Área Jurídica. Tese de Doutorado, Programa de Pós- Graduação em Ciência da Computação, Universidade Federal de Minas Gerais, [72] MARIANO FERNANDEZ, ASUNCION GOMEZ-PEREZ, NATALIA JURISTO. METHON- TOLOGY: from Ontological Art towards Ontological Engineering. Proceedings of the AAAI97 Spring Symposium Series on Ontological Engineering, [73] MARIANO FERNÁNDEZ LÓPEZ. Overview Of Methodologies For Building Ontologies. Proceedings of the IJCAI-99 Workshop on Ontologies and Problem-Solving Methods (KRR5), 1999.

121 Referências Bibliográficas 120 [74] MAURICIO ALMEIDA, MARCELLO BAX. Uma visão geral sobre ontologias: pesquisa sobre definições, tipos, aplicações, métodos de avaliação e de construção. Ci. Inf., Brasília, v. 32, n. 3, p. 7-20, [75] MediaWiki Free Software Wiki. Disponível em acessado em janeiro de [76] MICHAEL GRÜNINGER, MARK FOX. Methodology for the Design and Evaluation of Ontologies. IJCAI 95, Workshop on Basic Ontological Issues in Knowledge Sharing, [77] MICHAEL LESK. Understanding Digital Libraries. Second Edition. Morgan Kaufmann, [78] MICHAEL PAPAZOGLOU. Web Services: Principles and Technology. Prentice Hall, New Edition, [79] MICHEL BUFFA, GANDON, F., ERETEO, G., SANDER, P., FARON, C.. SweetWiki: A Semantic Wiki. Web Semantics, Pages 84-97, [80] MIKE USCHOLD, MARTIN KING. Towards a Methodology for Building Ontologies. Workshop on Basic Ontological Issues in Knowledge Sharing, held in conjunction with IJCAI-95, [81] MIKE USCHOLD, MICHAEL GRÜNINGER. Ontologies: Principles, Methods and Applications. Knowledge Engineering Review, Volume 11, Number 2, [82] MURILO BASTOS DA CUNHA. Desafios na Construção de uma Biblioteca Digital. Revista Ciência da Informação, Volume 28, Número 3, [83] MURILO BASTOS DA CUNHA. Das Bibliotecas Convencionais à Digitais: Diferenças e Convergências. Revista Ciência da Informação, Volume 13, Número 1, [84] MURILO MILTON MACHADO. Open Archives: Panorama dos Repositórios. Dissertação de Mestrado, Programa de Pós-Graduação em Ciência da Informação, Universidade Federal de Santa Catarina, [85] MyCoRe Digital Repository Software. Disponível em acessado em janeiro de [86] MySQL Open Source Database. Disponível em acessado em janeiro de 2010.

122 Referências Bibliográficas 121 [87] NATALYA NOY, DEBORAH MCGUINNESS. Ontology Development 101: A Guide to Creating Your First Ontology. Stanford Knowledge Systems Laboratory Technical Report KSL-01-05, [88] NATALYA NOY, MICHAEL SINTEK. Creating Semantic Web Contents with Protégé IEEE Intelligent Systems, [89] NICOLA GUARINO. Semantic Matching: Formal Ontological Distinctions for Information Organization, Extraction, and Integration. Information Extraction: A Multidisciplinary Approach to an Emerging Information Technology, Springer Verlag, [90] NICOLA GUARINO. Understanding, Building, and Using Ontologies: A Commentary to Using Explicit Ontologies in KBS Development, by van Heijst, Schreiber, and Wielinga. International Journal of Human and Computer Studies, [91] NICOLA GUARINO. Formal Ontology in Information Systems. Proceedings of FOIS 98, Trento, Italy, [92] OAICat Framework for OAI-PMH. Disponível em software/oai/cat.htm, acessado em janeiro de [93] OAI-PMH (Open Archives Initiative Protocol for Metadata Harvesting). Disponível em acessado em janeiro de [94] OAI Data Provider Registration. Disponível em data/registerasprovider.html, acessado em janeiro de [95] OIL Ontology Inference Layer. Disponível em acessado em janeiro de [96] ONTOWEB CONSORTIUM. A Survey on Ontology Tools. IST Programme of the Commission of the European Communities, [97] OAI Open Archives Initiative. Disponível em acessado em janeiro de [98] Open Archives Forum. Disponível em acessado em janeiro de [99] Open Society Institute. A Guide to Institutional Repository Software. 3rd Edition. New York, 2004.

123 Referências Bibliográficas 122 [100] OPUS Online Publications of the University of Stuttgart. Disponível em samos.bsz-bw.de, acessado em janeiro de [101] OSCAR CORCHO, MARIANO FERNÁNDEZ, ASUNCIÓN GÓMEZ, ANGEL LÓPEZ. Building legal ontologies with Methontology and WebODE. In Law and the Semantic Web, [102] OWL OWL Web Ontology Language. Disponível em acessado em janeiro de [103] OWL Web Ontology Language Overview. Disponível em /REC-owl-features , acessado em janeiro de [104] PATRÍCIA DE ANDRADE BUENO GARCIA. Provedores de Dados de Baixo Custo: Publicação Digital ao Alcance de Todos. Dissertação de Mestrado, Setor de Ciências Exatas, Universidade Federal do Paraná, [105] PATRÍCIA DE ANDRADE BUENO GARCIA, MARCOS SFAIR SUNYE. O Protocolo OAI- PMH para Interoperabilidade em Repositórios Digitais. I Congresso de Tecnologias para Gestão de Dados e Metadados do Cone Sul. Universidade Estadual de Ponta Grossa, Ponta Grossa Paraná, [106] PAUL J. DEITEL, HARVEY M. DEITEL. Java: How to Program. 7th Edition, Prentice Hall, [107] PAUL N. WEINBERG, ET AL. SQL The Complete Reference. McGraw-Hill Osborne Media, California, [108] PAUL SHABAJEE, A. D. Metadata the Gateway to the Web. Bera Leeds University, [109] PEAR::OAI Class Library for OAI-PMH. Disponível em acessado em janeiro de [110] PÉTER SCHÖNHOFEN, ANDRÁS BENCZÚR, ISTVÁN BÍRÓ, KÁROLY CSALOGÁNY. Cross-Language Retrieval with Wikipedia. In Proceedings of the Workshop of the Cross-Language Evaluation Forum (CLEF), [111] PHILIPP CIMIANO. Ontology Learning and Population from Text Algorithms, Evalution and Applications. Springer, [112] phpoai2 PHP Data Provider. Disponível em acessado em janeiro de 2010.

124 Referências Bibliográficas 123 [113] PKP Open Archives Harvester. Disponível em acessado em janeiro de [114] Protégé Ontology Editor and Knowledge Acquisition System. Disponível em acessado em janeiro de [115] PTStemmer A Java Stemming Toolkit for the Portuguese Language. Disponível em acessado em janeiro de [116] PubMed Central. Disponível em acessado em janeiro de [117] R. MIZOGUCHI. Ontology Engineering Environments. Handbook on Ontologies, Osaka, [118] RAJESH THIAGARAJAN, GEETHA MANJUNATH, MARKUS STUMPTNER. Computing Semantic Similarity Using Ontologies. International Semantic Web Conference (ISWC), Karlsruhe: Germany, [119] Registered Data Providers OAI. Disponível em Register/BrowseSites, acessado em janeiro de [120] RENAN RODRIGUES DE OLIVEIRA, CÁSSIO OLIVEIRA CAMILO, CEDRIC LUIZ DE CARVALHO E JOÃO CARLOS DA SILVA. Recuperação Contextualizada de Documentos em Bibliotecas Digitais Integradas. 8th International Information and Telecommunication Technologies Symposium, 2009, Florianópolis, Brasil. I2TS 2009, [121] RENAN RODRIGUES DE OLIVEIRA, CEDRIC LUIZ DE CARVALHO. Bibliotecas Digitais e a solução Fedora (Flexible Extensible Digital Object Repository Architecture. Universidade Federal de Goiás, Instituto de Informática, [122] RENAN RODRIGUES DE OLIVEIRA, CEDRIC LUIZ DE CARVALHO. Implementação de Interoperabilidade entre Repositórios Digitais por meio do Protocolo OAI- PMH. Universidade Federal de Goiás, Instituto de Informática, [123] RENAN RODRIGUES DE OLIVEIRA, CEDRIC LUIZ DE CARVALHO. Introdução aos Algoritmos de Agrupamento. Universidade Federal de Goiás, Instituto de Informática, [124] RENAN RODRIGUES DE OLIVEIRA, CEDRIC LUIZ DE CARVALHO. Contextual Retrieval of Documents in Integrated Data Providers. International Conference on Computational Processing of Portuguese Language, Porto Alegre, Brazil. Propor 2010), 2010.

125 Referências Bibliográficas 124 [125] RENAN RODRIGUES DE OLIVEIRA, CEDRIC LUIZ DE CARVALHO, DIRSON SANTOS DE CAMPOS. Contextualized Retrieval of Documents in Semantic Environments. IADIS International Conference, e-society 2010, Porto, Portugal. IADIS e-society 2010 (ES 2010), [126] Repository Explorer. Disponível em acessado em janeiro de [127] RICARDO BAEZA-YATES, BERTHIER RIBEIRO-NETO. Modern Information Retrieval. New York: Addison-Wesley, [128] RICARDO SHOITI IKEMATU. Gestão de Metadados: Sua Evolução na Tecnologia da Informação. Revista Ciência da Informação, Volume 2, Número 6, [129] RUDI STUDER, V. RICHARD BENJAMINS, DIETER FENSEL. Knowledge Engineering: Principles and Methods. Data Knowledge Engineering, Amsterdam, [130] RVOT Rapid Visual OAI Tool. Disponível em acessado em janeiro de [131] S. E. ROBERTSON, K. SPARCK-JONES. Relevance weighting of search terms. Journal of the American Society for Information Science, [132] S. E. ROBERTSON, S. WALKER. Okapi/keenbow at TREC-8. Proceedings of the Eighth Text REtrieval Conference (TREC-8), [133] S. E. ROBERTSON, S. WALKER, S. JONES, M. M. HANCOCK-BEAULIEU, M. GAT- FORD. Okapi at TREC-3. Proceedings of the Third Text REtrieval Conference (TREC-3), [134] SANDRO J. RIGO, JOSÉ PALAZZO M. DE OLIVEIRA, CRISTIANO BARBIERI. Classificação de textos baseada em ontologias de domínio. Anais do XXVII Congresso da SBC V Workshop em Tecnlogia da Informação e da Linguagem Humana, [135] SAYÃO, L. F. Bibliotecas Digitais e suas Utopias. Revista Ponto de Acesso, Volume 2, Número 2, [136] SCOTT DEERWESTER, SUSAN T. DUMAIS, GEORGE W. FURNAS, THOMAS K. LAN- DAUER, RICHARD HARSHMAN. Indexing by Latent Semantic Analysis. Journal of the American Society for Information Science, [137] SDLIP Simple Digital Library Interoperability Protocol. Disponível em acessado em janeiro de 2010.

126 Referências Bibliográficas 125 [138] SEAN BECHHOFER, IAN HORROCKS, CAROLE GOBLE, ROBERT STEVENS. OilEd: a Reason-able Ontology Editor for the Semantic Web. Proceedings of KI2001, Joint German/Austrian conference on Artificial Intelligence, [139] SEBASTIAN RYSZARD KRUK, BILL MCDANIEL. Semantic Digital Libraries. Springer, [140] SHIH-HUNG WU, TZONG-HAN TSAI, WEN-LIAN HSU. Text Categorization Using Automatically Acquired Domain Ontology. Sixth International Workshop on Information Retrieval with Asian Languages (IRAL-03), Sapporo: Japan, [141] SHOE Simple HTML Ontology Extensions. Disponível em edu/projects/plus/shoe, acessado em janeiro de [142] SRU Search/Retrieval via URL. Disponível em acessado em janeiro de [143] SRW Search and Retrieve Web Service. Disponível em acessado em janeiro de [144] STEFFEN STAAB, HANS-PETER SCHNURR, RUDI STUDER, YORK SURE. Knowledge Processes and Ontologies. IEEE Intelligent Systems, [145] STEPHAN BLOEHDORN, PHILIPP CIMIANO, ANDREAS HOTHO. Learning Ontologies to Improve Text Clustering and Classification. Springer, Berlin Heidelberg, Germany, [146] STEPHEN M. GRIFFIN. NSF/DARPA/NASA Digital Libraries Initiative: A Program Manager s Perspective. D-Lib Magazine, Vol. 4, [147] STEPHEN REED, DOUGLAS LENAT. Mapping Ontologies into Cyc. Cycorp, Inc, [148] SUELI MARA FERREIRA, LEONARDO FERNANDES SOUTO. Sistemas de Informação Federados à Federação de Bibliotecas Digitais. Revista Brasileira de Biblioteconomia e Documentação. Nova Série, São Paulo, v. 2, n. 1, p.23-40, [149] SYED, Z., FININ, T., JOSHI, A.. Wikipedia as an Ontology for Describing Documents. 3rd Int l AAAI Conference on Weblogs and Social Media (ICWSM 08), [150] TEFKO SARACEVIC. Digital Library Evaluation: Toward an Evolution of Concepts. Library Trends, 2000.

127 Referências Bibliográficas 126 [151] THOMAS GRUBER. Ontolingua: A Mechanism to Support Portable Ontologies. Knowledge Systems, AI Laboratory, [152] THOMAS GRUBER. A Translation Approach to Portable Ontology Specifications. Knowledge Systems Laboratory, Computer Science Department, Stanford University, [153] THOMAS K. LANDAUER, PETER W. FOLTZ, DARRELL LAHAM. Introduction to Latent Semantic Analysis. Discourse Processes, 25, , [154] TIM BERNERS-LEE. Metadata Architeture: Documents, Metadata and Links. Axioms of Web Architecture, W3C, [155] TIM CONVERSE, JOYCE PARK. PHP Bible. 2nd Edition, Wiley, [156] TONY GILL, ANNE J. GILLILAND, MAUREEN WHALEN, MARY S. WOODLEY. Introdution to Metadata. Online Edition, Version 3.0. Disponível em acessado em janeiro de 2010, [157] W3C World Wide Web Consortium. Disponível em acessado em janeiro de [158] Wikibooks. Disponível em acessado em janeiro de [159] Wikimedia Foundation. Disponível em acessado em janeiro de [160] Wikimedia Commons. Disponível em acessado em janeiro de [161] Wikinews. Disponível em acessado em janeiro de [162] Wikipédia. Disponível em acessado em janeiro de [163] Wikiquote. Disponível em acessado em janeiro de [164] Wikisource. Disponível em acessado em janeiro de [165] Wikispecies. Disponível em acessado em janeiro de [166] Wikiversity. Disponível em acessado em janeiro de [167] Wiktionary. Disponível em acessado em janeiro de 2010.

128 Referências Bibliográficas 127 [168] WILLIAM Y. ARMS, DAVE FULKER NAOMI, CARL LAGOZE. A Case Study in Metadata Harvesting: the NSDL. Disponível em acessado em janeiro de [169] Web Services Architecture. Disponível em acessado em outubro de [170] XOL Ontology Exchange Language. Disponível em xol, acessado em janeiro de [171] YAN HUANG. Support Vector Machines for Text Categorization Based on Latent Semantic Indexing. Johns Hopkins University, [172] YONGGANG QIU, HANS-PETER FREI. Concept Based Query Expansion. SIGIR: ACM Special Interest Group on Information Retrieval, [173] YORK SURE, MICHAEL ERDMANN, JUERGEN ANGELE. OntoEdit: Collaborative Ontology Development for the Semantic Web. ISWC 2002: International Semantic Web Conference, [174] ZHANJUN LI, VICTOR RASKIN, KARTHIK RAMANI. A Methodology of Engineering Ontology Development for Information Retrieval. International Conference on Engineering Design, ICED 07, [175] ZMARCO Project Data Provider. Disponível em acessado em janeiro de 2010.

129 Respostas de Requisições do Protocolo OAI-PMH APÊNDICE A Neste Apêndice, apresenta-se trechos das respostas em XML relativas aos exemplos de requisições do protocolo OAI-PMH que foram listadas na Seção 3.5 desta dissertação. Para os arquivos mais extensos, são apresentados apenas trechos das respostas em XML. Figura A.1: Trecho da resposta da Requisição 1, referente ao verbo Identify Figura A.2: Trecho da resposta da Requisição 2, referente ao verbo ListMetadataFormats

130 Apêndice A 129 Figura A.3: Trecho da resposta da Requisição 3, referente ao verbo ListMetadataFormats Figura A.4: Resposta da Requisição 4, referente ao verbo ListMetadataFormats Figura A.5: Trecho da resposta da Requisição 5, referente ao verbo ListRecords

131 Apêndice A 130 Figura A.6: Trecho da resposta da Requisição 6, referente ao verbo ListRecords Figura A.7: Trecho da resposta da Requisição 7, referente ao verbo ListRecords

132 Apêndice A 131 Figura A.8: Trecho da resposta da Requisição 8, referente ao verbo ListIdentifiers Figura A.9: Trecho da resposta da requisição 9, referente ao verbo ListIdentifiers Figura A.10: Trecho da resposta da requisição 10, referente ao verbo ListIdentifiers

133 Apêndice A 132 Figura A.11: Trecho da resposta da Requisição 11, referente ao verbo GetRecord Figura A.12: Resposta da Requisição 12, referente ao verbo GetRecord

134 Apêndice A 133 Figura A.13: Resposta da Requisição 13, referente ao verbo GetRecord Figura A.14: Trecho da resposta da Requisição 14, referente ao verbo ListSets