Um Provedor de Dados para Bibliotecas Digitais Compatível com o Padrão OAI 1

Transcrição

1 Um Provedor de Dados para Bibliotecas Digitais Compatível com o Padrão OAI 1 Diego Fraga Contessa, Daniel Lazzarotto, José Palazzo Moreira de Oliveira Instituto de Informática Universidade Federal do Rio Grande do Sul (UFRGS) Caixa Postal Porto Alegre RS Brasil {contessa,lazza,palazzo}@inf.ufrgs.br Abstract. This paper presents a proposal for the adaptation of the Journal and Event Management System (JEMS), enabling it to work as a data provider compatible with the Open Archives Initiative model. To achieve this goal, the paper lists the changes that must be made in the system and the new modules that must be developed. Resumo. Este artigo apresenta uma proposta para a adaptação do sistema de submissão de artigos JEMS de forma a torná-lo um provedor de dados compatível com o modelo proposto pela Iniciativa de Arquivos Abertos. Para isso são listadas as mudanças que devem ser feitas no sistema, além dos novos módulos que devem ser criados. 1. Introdução A publicação de trabalhos científicos é uma das principais formas de avanço da ciência, dando aos autores o reconhecimento de seu trabalho por parte da comunidade científica. A medida da aceitação ou qualidade de um trabalho pode ser calculada pelo número de vezes que ele é referenciado [Silva 2004]. Porém, a publicação de artigos científicos pode ser resultado de um processo bastante complicado, que passa pela avaliação do trabalho por comitês especializados no assunto do trabalho, para posterior aceitação. Além disso, há muitas vezes a necessidade de resolver problemas burocráticos relativos aos direitos autorais e à propriedade intelectual do trabalho. Neste contexto, as bibliotecas digitais surgem como uma alternativa para simplificar o processo de publicação de artigos. Estas bibliotecas caracterizam-se como repositórios de dados que possuem meta-informações sobre os artigos publicados e links para os artigos propriamente ditos. Um exemplo de biblioteca digital é a BDBComp [Laender 2004] que constitui-se em um repositório de artigos publicados em Computação no Brasil. Porém, a implementação e uso das bibliotecas digitais devem 1 Este trabalho foi parcialmente financiado pelos projetos PERMML, proc /2004-0, e DIGITE, proc /2005-5, do CNPq. 21

2 fornecer mecanismos de interoperabilidade e padronização dos metadados que serão utilizados pelos repositórios. Essas questões podem ser resolvidas através da Iniciativa de Arquivos Abertos (Open Archives Initiative - OAI) [OAI 2005] e pelo formato Dublin Core [Dublin Core 2005]. O objetivo principal do trabalho apresentado neste artigo é o desenvolvimento de um serviço de geração de metadados sobre artigos publicados nas conferências ou periódicos da SBC (Sociedade Brasileira de Computação). Os metadados gerados serão disponibilizados para bibliotecas digitais como, por exemplo, a BDBComp. Esse serviço será desenvolvido como um módulo do sistema JEMS (Journal and Event Management System) [JEMS 2005], o qual é baseado no EDAS [Schulzrinne 2005]. O JEMS é o sistema de gerenciamento de submissões de artigos da SBC (Sociedade Brasileira de Computação). O serviço deve ser compatível com o padrão OAI. Neste artigo são apresentadas as tecnologias, sistemas e padrões envolvidos, bem como a proposta do sistema de geração de metadados para bibliotecas digitais e a arquitetura desenvolvida para esse sistema. A seguir são apresentados os principais conceitos envolvidos no trabalho, mostrando o padrão OAI e o formato Dublin Core, além dos sistemas da BDBComp e do JEMS. Em seguida, serão mostrados os módulos adicionais ao JEMS, e os metadados que serão disponibilizados no padrão OAI. 2. Conceituação A arquitetura aqui descrita envolve padrões abertos para o desenvolvimento de sistemas cujo objetivo é a interoperabilidade. Alguns dos padrões e sistemas fundamentais ao desenvolvimento do trabalho são apresentados nesta seção Iniciativa de Arquivos Abertos Tendo em vista que cada biblioteca digital é suportada por um sistema independente, que pode ser implementado de forma completamente diferente dos demais, é evidente que um ponto onde existe uma significativa dificuldade é a interoperabilidade. Essa característica, a interoperabilidade, é interessante, pois permite a troca de metadados entre diferentes bibliotecas digitais. Para tentar minimizar esse problema, foi criada a Iniciativa de Arquivos Abertos OAI (sigla para Open Archives Initiative) [OAI 2005]. Nessa abordagem, o termo arquivo se refere a um depósito de textos completos, e o termo aberto se refere à arquitetura do sistema, que define interfaces que facilitam a disponibilização de conteúdos procedentes de diversos provedores [Silva 2005]. A justificativa para a criação e adoção da OAI é o fato desta iniciativa facilitar a disseminação dos artigos científicos, o que traz um aumento da oferta e uma rápida divulgação dos trabalhos desenvolvidos pela comunidade científica. A coleta dos metadados dos artigos por parte das bibliotecas digitais é feita usando o protocolo OAI-PMH (Open Archives Initiative Protocol for Metadata Harvesting) [PMH 05]. Esse protocolo define como deve ser feita a transferência de metadados entre computadores (provedores de dados e de serviços). O padrão OAI define duas entidades básicas: os provedores de dados e os provedores de serviços. Os provedores de dados têm a função de buscar metadados em bases de dados, e disponibilizá-los suportando o protocolo OAI-PMH. Os provedores de serviços, por sua 22

3 vez, utilizam os metadados disponibilizados pelo provedor de dados para fornecer serviços mais específicos. A Figura 1 apresenta o funcionamento básico do protocolo OAI-PMH. Os provedores de serviços implementam um harvester, o qual busca metadados em um provedor de dados. Para isso, eles enviam requisições baseadas em HTTP aos provedores de dados, os quais possuem repositórios onde buscam os metadados, para em seguida retorná-los aos provedores de serviços por meio de documentos ML. Figura 1: Funcionamento básico do OAI-PMH [OAI 2005] Os metadados são retornados em formatos específicos, os quais devem ser reconhecidos pelo provedor de serviços e pelo provedor de dados. Os metadados formatados segundo um esquema definido são chamados de registros (records). Cada item em um repositório possui um identificador único, de modo que pode ser recuperado diretamente. Os repositórios podem ser logicamente particionados por conjuntos (sets) de metadados. O OAI-PMH define seis tipos de requisição. Um harvester não é obrigado a usar todos os tipos, mas um repositório necessita interpretar e responder a todos [OAForum 2005]. Os seis tipos são apresentados a seguir: Identify: retorna a descrição de um arquivo ; ListMetadataFormats: recupera os formatos disponíveis de metadados em um arquivo ; ListSets: Retorna uma lista de conjuntos de um repositório; ListRecords: Busca uma lista de registros de um repositório; ListIdentifiers: Recupera os identificadores de todos os registros de um repositório; GetRecord: Recupera um registro individual de um repositório; Os repositórios devem implementar mecanismos de controle de fluxo, de modo a particionar listas muito grandes de metadados. O controle de fluxo pode ser feito por meio de resumption tokens, que são uma espécie de apontadores para itens da lista de metadados, conhecidos pelo repositório, que marcam até que ponto da lista os metadados já foram retornados Dublin Core A padronização do conjunto de metadados que são utilizados pelas bibliotecas digitais é também uma questão importante para a interoperabilidade entre bibliotecas. Para isso adotou-se o formato Dublin Core [Dublin Core 2005], que tem como objetivo principal identificar e definir um conjunto mínimo de elementos capazes de descrever recursos disponíveis na Internet. 23

4 O Dublin Core define um conjunto de 15 elementos (Dublin Core Metadata Element Set - DCMES), sendo todos recomendados e nenhum obrigatório [Dublin Core 2005]. Esses elementos descrevem um objeto através do título, do criador, do assunto, da descrição, do tipo, da data, do formato, entre outros. Além desses, há extensões com elementos opcionais e qualificadores. A Tabela 1 apresenta os metadados do Dublin Core Qualificado, que é formado pelos metadados básicos do Dublin Core, mais o campo Audience. Tabela 1. Metadados do Dublin Core Qualificado Elemento Audience Contributor Coverage Creator Date Description Identifier Format Language Publisher Rights Relation Source Subject Title Type Descrição A quem o trabalho se destina Pessoas que contribuíram para o trabalho Área de abrangência do trabalho Autores dos trabalho Data de disponibilização do trabalho Descrição do trabalho (para artigos, um abstract) Um identificador único para o trabalho, como um ISBN ou uma URL Formato em que é disponibilizado o trabalho Idioma do trabalho publicado Informações sobre o responsável pela publicação do trabalho Descrição da propriedade intelectual ou direito autorais Relacionamento com outros trabalhos, se houver Outras fontes das quais o trabalho se deriva, se houverem Assunto do qual trata o trabalho Titulo de um trabalho Tipo do objeto 2.3. BDBComp Biblioteca Digital Brasileira de Computação A BDBComp [Laender 2004, Silva 2005] surgiu com o objetivo de disponibilizar as informações dos trabalhos da comunidade brasileira de computação, permitindo assim a disseminação dos resultados para toda a comunidade. Ela adota o padrão OAI e o formato Dublin Core para os metadados. Atualmente, a BDBComp realiza a colheita (harvesting) de metadados em páginas Web, gerando os metadados a partir das páginas HTML das conferências da SBC. Um dos objetivos do sistema proposto neste artigo é oferecer a possibilidade da BDBComp se utilizar dos metadados dos artigos publicados nas conferências da SBC, a partir do sistema JEMS, por meio de um provedor de dados compatível com o padrão OAI, que realiza a colheita de metadados diretamente dos artigos publicados. 24

5 2.4. JEMS Journal and Event Management System O sistema JEMS (Journal and Event Management System) [JEMS 2005] recebe as submissões dos artigos das conferências e periódicos da Sociedade Brasileira de Computação. Atualmente, os metadados armazenados por ele não são disponibilizados. Esse sistema é uma versão atualizada do EDAS [Schulzrinne 2005], com correções de bugs e adição de funcionalidades mais avançadas. O JEMS possui dois processos, cadastro de autores, e submissão de artigos. Através destes dois processos o sistema obtém metadados dos artigos e dos autores. Além disso, há metadados sobre as conferências ou periódicos (comitê de avaliação dos artigos, datas, prazos, entre outros). Os artigos passam pelo processo de avaliação e são marcados como aceitos ou rejeitados. Aos autores de artigos aceitos, em geral, é solicitado o envio de uma versão final do artigo. 3. Serviço de Provedor de Dados para o JEMS A Figura 2 apresenta o serviço para a geração automática ou semi-automática dos metadados dos artigos aprovados em conferências que utilizem o JEMS para gerenciar as submissões. Os metadados gerados são disponibilizados no formato Dublin Core a bibliotecas digitais, como a BDBComp, para que elas possam utilizar os metadados dos artigos registrados no JEMS em seus repositórios. Para isso, do ponto de vista do JEMS, é necessário implementar modificações no processo de submissão de artigos e no processo de gerenciamento dos eventos e publicações. Deve-se adicionar um módulo que solicite ao coordenador do comitê de programa de um evento alguns dados que não são disponibilizados atualmente, como por exemplo, informações sobre a publicação e o meio de disponibilização do artigo. Além disso, deve ser acrescentado ao JEMS um módulo de solicitação de metadados sobre o artigo, que complementam os dados já existentes, os quais são solicitados no momento da submissão da primeira versão do artigo. Essa solicitação deve ocorrer quando o autor for submeter a versão final de seu artigo para publicação. Exemplos de metadados que podem ser solicitados são: informações sobre idioma, relação com outros trabalhos, entre outros. Esses módulos complementam a aquisição de metadados pelo JEMS, os quais serão utilizados por um provedor de dados para que sejam disponibilizados para as bibliotecas digitais. 25

6 Figura 2. Esquema geral do serviço proposto Conforme apresentado pela Figura 2, um usuário (autor de um artigo) submete seu trabalho a alguma conferência cadastrada no JEMS, usando a interface já existente no sistema. A partir disso, há o processo de avaliação do artigo submetido, que fica a cargo do comitê de programa cadastrado no sistema. Ao final, o coordenador deste comitê de programa marca os artigos que foram submetidos como aprovados ou rejeitados. Aqueles autores que tiverem seu artigo aprovado poderão enviar sua versão final, levando em consideração as alterações solicitadas pelo comitê de programa. Neste ponto, o sistema deve ser modificado para conter formulários onde o coordenador do comitê inclui no sistema informações sobre o evento ou publicação. A partir disso, o sistema fica apto a receber as versões finais dos artigos do referido evento ou publicação. No momento em que um autor for submeter a versão final de seu artigo, o sistema deverá apresentar um formulário novo, para que o mesmo inclua informações adicionais sobre o trabalho que ainda não constem da base de dados do JEMS. A partir desta ação o sistema solicitará o envio da nova versão do artigo. Desse modo pode-se completar o conjunto de metadados disponíveis, permitindo a posterior disponibilização dos mesmos a bibliotecas digitais por um provedor de dados compatível com o padrão OAI. 4. Arquitetura do provedor de dados proposto Este trabalho está desenvolvendo um provedor de dados compatível com o padrão OAI, implementando o suporte ao protocolo OAI-PMH. A Figura 3 apresenta a arquitetura proposta para o sistema, baseada na arquitetura geral de um provedor de dados apresentada em [OAForum 2005]. O provedor de dados recebe uma requisição HTTP, e realiza a validação da mesma através de um parser. Em seguida, o módulo de extração dos metadados realiza a busca de metadados no repositório e nos próprios artigos e, de acordo com o controle de fluxo, gera as respostas em ML. No caso de ocorrência de erros, entra em funcionamento o módulo de geração de erros, que também retorna um arquivo ML. A Figura 3 apresenta a arquitetura do sistema proposto. 26

7 JEMS Artigos JEMS Novo Form. (Chair) Novo Form. (Usuário) Solicitação de Metadados MySQL JEMS Requisição OAI (HTTP) 1º Workshop em Bibliotecas Digitais Validação da Requisição Extração de Metadados Montagem das Consultas Consultas Arq. Consultas SQL Recebimento das Respostas Geração de Erros (ML) Geração de Respostas (ML) Controle de Fluxo PROVEDOR DE DADOS Resposta OAI (ML) Figura 3: Arquitetura do sistema proposto Nota-se na arquitetura, apresentada na Figura 3, a existência dos dois módulos adicionais do sistema JEMS. O primeiro deles é o provedor de dados, que é o responsável pelo recebimento de solicitações, busca das informações no JEMS e envio das respostas. O segundo consiste em dois formulários de solicitação de metadados adicionais. Também é prevista a adaptação da base de dados do JEMS para receber esses novos metadados. Com base em trabalhos relacionados, como [Warpechowski 2005], espera-se posteriormente estender esse serviço com um maior número de metadados, além dos do formato Dublin Core. Dessa forma, será possível atender outros tipos de necessidades de diferentes harvesters. A Figura 4 apresenta o esquema preliminar do repositório de metadados a ser implementado. Esse esquema foi feito com base na estrutura dos metadados do padrão Dublin Core Qualificado, de modo a facilitar o armazenamento e posterior recuperação dos metadados. Figura 4: Modelo preliminar da base de dados do repositório 27

8 A Tabela 2 apresenta os metadados que serão disponibilizados, citando a fonte de cada um. A coluna BD JEMS representa os metadados que podem ser recuperados a partir do banco de dados do JEMS. A coluna Arquivos representa os metadados que podem ser recuperados automaticamente pela análise dos arquivos submetidos. A coluna Autor e Chair representam, respectivamente, os novos formulários que deverão ser preenchidos pelo autor do trabalho e pelo chair do evento. O provedor de dados deverá reconhecer e responder corretamente às seis diferentes requisições do OAI-PMH, de modo a poder ser utilizado pelas bibliotecas digitais. A implementação dos módulos do provedor de dados e do repositório é hospedada no mesmo servidor que abriga o JEMS, de modo que a base de dados e os artigos sejam facilmente acessíveis para o processo de geração de metadados. Com isso, o que se obtém é a extensão do JEMS para que este passe a se comportar como um provedor de dados do padrão OAI. Metadados Audience Contributor Coverage Creator Date Description Identifier Format Language Publisher Rights Relation Source Subject Title Type 5. Considerações finais Tabela 2. Origem dos metadados BD JEMS Arquivos Form. Novo Autor Chair O trabalho proposto oferece uma implementação de um provedor de dados do padrão OAI, que suporta o protocolo OAI-PMH. Com isso, espera-se facilitar o arquivamento dos artigos, e promover o uso dos metadados, contidos no sistema JEMS, sobre os artigos publicados em bibliotecas digitais, de modo a disseminar os resultados dos trabalhos de forma eficiente. Com o serviço apresentado deixa-se de ter a necessidade de inserção manual dos metadados nas bibliotecas digitais, sendo automática a utilização dos metadados disponibilizados. Além disso, remove-se a necessidade de fazer com que as bibliotecas digitais realizem varreduras nas páginas dos eventos em busca de metadados sobre os artigos publicados, já que os mesmos estarão disponíveis no formato Dublin Core Qualificado, que é utilizado amplamente. Dessa forma, é oferecida uma maior riqueza de metadados às bibliotecas digitais. 28

9 A BDBComp poderá se utilizar do provedor de dados implementado para a aquisição automática de metadados para seus repositórios. Além disso, outro resultado importante é a adição de funcionalidades ao sistema JEMS, o qual conterá interfaces novas para o início do período de submissão de versões finais e para o envio por parte dos autores das mesmas, o que estimulará os autores a informarem os metadados que se deseja disponibilizar. Referências Dublin Core. (2005) Dublin Core Metadata Initiative, Disponível em < Acessado em: Abril de JEMS. (2005) Journal and Event Management System, Disponível em < Acessado em: Julho de Laender, A. H. F., Gonçalves, M. A., Roberto, P. A. (2004) BDBComp: building a digital library for the Brazilian computer science community, Proceedings of the 4th ACM/IEEE-CS joint conference on Digital libraries 2004, Tuscon, AZ, USA, June 07-11, 2004, pp OAI. (2005) Open Archives Initiative, Disponível em < Acessado em: Abril de OAForum. (2005) Open Archives Forum: OAI-PMH Online Tutorial, Disponível em < Acessado em: Abril de PMH. (2005) The Open Archives Initiative Protocol for Metadata Harvesting, Disponível em < Acessado em: Janeiro de Schulzrinne, H. (2005) Editor s Assistant v3, Disponível em < Acessado em: Abril de Silva, L. V. (2004) Um Serviço de Auto-arquivamento de Publicações Científicas compatível com o Padrão OAI, Dissertação (Mestrado). Belo Horizonte, UFMG Universidade Federal de Minas Gerais. Warpechowski, M., Oliveira, J. P. M. (2005) Retrieval of Learning Objects Metadata in AdaptWeb, In proceedings of thecaise 05 Workshops, Porto, Portugal, RS. 29