2.3 O Protocolo OAI-PMH
2.5.4 Quadro Comparativo dos Sistemas
Nesta se¸c˜ao mostramos um quadro comparativo, apresentado na Tabela 2.5, de todos os sistemas descritos, identificando detalhes adicionais e fun¸c˜oes particulares. O objetivo dessa compara¸c˜ao n˜ao ´e distinguir o melhor servi¸co de auto-arquivamento dentre os sistemas des- critos, pois cada um possui caracter´ısticas espec´ıficas para o seu ambiente de trabalho. Em cada institui¸c˜ao o sistema mais indicado ser´a o que melhor atender a seus requisitos e necessidades.
Caracter´ısticas Dspace Eprints Kepler
Vers˜ao do protocolo OAI-PMH OAI-PMH 2.0 OAI-PMH 2.0 OAI-PMH 2.0 Licen¸ca de software livre BSD GNU GPL n˜ao ´e software livre
Plataformas Java Perl Java PostgreSQL MySQL MySQL/Oracle Unix/Windons Linux/Solaris Linux/Windons
Apache Apache Arc1
qualquer browser qualquer browser qualquer browser Tomcat TomCat ´
Ultima atualiza¸c˜ao Agosto-03 Mar¸co-02 Outubro-04 Cadastramento de usu´arios sim sim n˜ao Processo seguro de gera¸c˜ao sim sim n˜ao
de senha2
Mecanismo de autentica¸c˜ao email/X.509 tabelas MySQL sim3
do usu´ario (e-mail e senha) (login name e senha)
Restri¸c˜ao de usu´arios4 sim n˜ao n˜ao
Perfil do usu´ario armazenado sim sim n˜ao Autoriza¸c˜oes diferentes por sim sim sim
usu´arios
M´ultiplos n´ıveis de acesso sim n˜ao sim3
ao servi¸co5
Restri¸c˜ao de acesso ao sim sim sim conte´udo do objeto digital
M´ultiplos conte´udos de cole¸c˜oes6 sim sim sim
Est´agios do objeto digital assemble n˜ao possui n˜ao possui
pending approved
Submiss˜ao incompleta7 sim sim8 n˜ao
Usu´arios envolvidos submitters user publicadores indi-
reviewers editor viduais
approvers administrator usu´arios gerais
editors
Tipos de objeto digital qualquer9 eprints10 qualquer
Tipos de submiss˜ao institucional e institucional e individual individual individual
Acesso ao texto completo sim sim sim (URL e (URL e (texto completo) texto completo) texto completo)
Notifica¸c˜ao ao usu´ario sobre sim sim n˜ao estado do objeto
Notifica¸c˜ao ao administrador sim sim n˜ao sobre objetos `a espera de
aprova¸c˜ao
Acesso ao conte´udo e sim sim sim pendˆencias da submiss˜ao
Formato de metadados Dublin Core Dublin Core Dublin Core Qualificado
Sustenta¸c˜ao de outros formatos sim sim sim Controle de qualidade dos sim accept n˜ao
metadados edit bounce
delete
Sele¸c˜ao de objetos para sim sim sim colheita via OAI-PMH
A seguir apresentamos algumas considera¸c˜oes relevantes referentes ao quadro comparativo: (1) Arc ´e um servi¸co de colheita e recupera¸c˜ao de dados para m´ultiplos provedores de dados
[28].
(2) Caracter´ıstica que fornece um processo seguro de gera¸c˜ao de senhas, para o caso dos
usu´arios que esqueceram as suas senhas possam receber uma nova. Normalmente as senhas s˜ao enviadas via e-mail.
(3) Em Kepler o usu´ario (provedores de dados individuais) s˜ao autenticados atrav´es de URLs
e IP’s pelos servidores centrais.
(4) Caracter´ıstica que restringe o tipo de usu´arios que podem usar o servi¸co de auto-
arquivamento.
(5) Caracter´ıstica na qual o administrador aplica m´ultiplos n´ıveis de restri¸c˜ao de acesso para
entrada do servi¸co de auto-arquivamento, como por exemplo, acesso livre, acesso atrav´es de IP e acesso atrav´es de login name e senha.
(6) Caracter´ıstica na qual m´ultiplos conte´udos de cole¸c˜oes e/ou grupos de usu´arios s˜ao
definidos. Cole¸c˜oes podem ser definidas de v´arias formas incluindo ´area de conhecimento e tipos. E usu´arios podem ser divididos por institui¸c˜oes.
(7) Caracter´ıstica na qual permite que submiss˜oes sejam auto-arquivadas de forma incom-
pleta sem passar pelo est´agio de aprova¸c˜ao. Isto ´e realizado para simplificar o processo de submiss˜ao, permitindo que o usu´ario salve a submiss˜ao incompleta e posteriormente continue o processo de submiss˜ao.
(8) No Eprints o estado da submiss˜ao ´e armazenado no banco de dados.
(9) Dspace armazena objetos complexos.
(10) Eprints pode ser configurado para armazenar outro tipo de objetos al´em de objetos do
O Servi¸co de Auto-Arquivamento da
BDBComp
Neste cap´ıtulo, descrevemos o servi¸co de auto-arquivamento criado para a Biblioteca Di- gital Brasileira de Computa¸c˜ao (BDBComp). Na Se¸c˜ao 3.1 ´e mostrada uma vis˜ao geral da BDBComp. Na Se¸c˜ao 3.2 ´e apresentada a arquitetura do servi¸co de auto-arquivamento. Na Se¸c˜ao 3.3 s˜ao apresentados os poss´ıveis usu´arios desse servi¸co. Na Se¸c˜ao 3.4 s˜ao ilustradas as fun¸c˜oes e caracter´ısticas do servi¸co de auto-arquivamento. Na Se¸c˜ao 3.5 ´e descrito o reposit´orio de metadados. Na Se¸c˜ao 3.6 s˜ao apresentas as interfaces do servi¸co de auto- arquivamento. Por fim, ´e realizada uma compara¸c˜ao entre o servi¸co de auto-arquivamento da BDBComp e os sistemas descritos no Cap´ıtulo 2.
3.1
Vis˜ao Geral da BDBComp
O projeto da BDBComp surgiu no Laborat´orio de Bancos de Dados do DCC/UFMG com o objetivo de disponibilizar na Web informa¸c˜oes bibliogr´aficas referentes a trabalhos (pu- blica¸c˜oes de tipo post-prints) da comunidade brasileira de computa¸c˜ao, suprindo, assim, a carˆencia de um acervo brasileiro na ´area e permitindo que pesquisadores disseminem seus trabalhos para toda a comunidade [25]. A BDBComp foi projetada de acordo com o padr˜ao OAI e adota o formato Dublin Core para seus metadados. A BDBComp est´a dispon´ıvel em http://www.lbd.dcc.ufmg.br/bdbcomp e, atualmente, possui registros de metadados de 3401 trabalhos apresentados em eventos promovidos pela Sociedade Brasileira de Computa¸c˜ao (SBC), dos quais 972 incluem o resumo do trabalho e 1084 o link para o texto completo1.
A arquitetura da BDBComp, mostrada na Figura 3.1, compreende trˆes camadas principais: as interfaces de usu´arios, os servi¸cos oferecidos pela biblioteca e o reposit´orio de metadados.
Figura 3.1: Arquitetura da BDBComp.
As interfaces servem para agrupar todos os servi¸cos fornecidos, existindo, assim, diferentes interfaces de acordo com a necessidade das diferentes comunidades de usu´arios.
Na atual vers˜ao da BDBComp est˜ao dispon´ıveis os servi¸cos de busca, navega¸c˜ao e listagem de trabalhos mais recentes, com facilidades similares aos servi¸cos dispon´ıveis na DBLP [27], existindo tamb´em um servi¸co de provedor de dados baseado no protocolo OAI-PMH. Al´em dos servi¸cos mencionados, pretende-se tamb´em oferecer futuramente servi¸cos mais avan¸cados, tais como, filtragem, linking autom´atico e recomenda¸c˜oes. O servi¸co de auto-arquivamento encontra-se na camada de servi¸cos e possui o papel fundamental de fornecer metadados para o reposit´orio atrav´es das submiss˜oes de trabalhos realizados por pesquisadores. Os usu´arios que interagem com esse servi¸co s˜ao diferenciados de outros usu´arios dos servi¸cos mencionados. Para manter os servi¸cos mencionados existem tamb´em servi¸cos especiais de administra¸c˜ao.
Finalmente, no n´ıvel mais interno da arquitetura, encontramos o reposit´orio central que armazena os metadados que descrevem os trabalhos dispon´ıveis. Al´em do servi¸co de auto-arquivamento, foram previstas outras duas maneiras de se coletar metadados para o reposit´orio da BDBComp:
1. Extra¸c˜ao de metadados de sites existentes na Web, por exemplo, usando ferramentas tais como as utilizadas pelo ambiente Web-DL [4].
2. Colheita de metadados de outros reposit´orios (por exemplo, CITIDEL [6]) que supor- tam o protocolo OAI-PMH.
O reposit´orio da atual vers˜ao da BDBComp foi criado a partir de dados extra´ıdos de alguns sites de eventos da SBC por meio de wrappers e do ambiente Web-DL. Esse reposit´orio ´e um banco de dados relacional que, atualmente, compreende somente trabalhos publicados em eventos da SBC, cujo esquema ´e representado pelo diagrama ER da Figura 3.2.
Figura 3.2: Esquema atual do reposit´orio de metadados da BDBComp.
O esquema do reposit´orio inclui um tipo de entidade work que representa os trabalhos armazenados no reposit´orio. Este tipo de entidade possui, al´em da chave prim´aria, um conjunto de atributos multivalorados, ou seja, que podem ter mais de um valor. Esses atributos representam os dados de um trabalho publicado em anais, como seu t´ıtulo, seus autores ou sua data de publica¸c˜ao.
O esquema proposto foi desenvolvido de modo que atendesse ao formato de metadados Dublin Core Simples, onde cada um dos 15 atributos multivalorados do tipo de entidade work representa um dos campos do formato. A raz˜ao para os atributos serem multivalorados ´e o fato de o formato Dublin Core permitir que cada um dos seus campos possua mais de um valor.
Uma outra caracter´ıstica do esquema do reposit´orio ´e o suporte ao protocolo OAI-PMH. No protocolo, existe a no¸c˜ao de conjunto que serve para agrupar logicamente registros rela- cionados no reposit´orio de metadados. Assim, na BDBComp, existe um conjunto para cada
evento cujos dados est˜ao armazenados no reposit´orio de metadados.
Atrav´es deste trabalho, o reposit´orio atual foi modificado para englobar outros tipos de docu- mento, melhorar o desempenho para consultas dos servi¸cos descritos e permitir a constru¸c˜ao do servi¸co de auto-arquivamento, mantendo, por´em, as caracter´ısticas gerais do reposit´orio descrito.
3.2
Arquitetura
O servi¸co de auto-arquivamento desenvolvido provˆe facilidades para que indiv´ıduos, por exemplo pesquisadores, estudantes e profissionais, possam submeter os metadados de seus trabalhos ao reposit´orio da BDBComp. ´E um servi¸co no qual os pr´oprios usu´arios s˜ao respons´aveis pela manuten¸c˜ao da biblioteca, participando do processo de submiss˜ao e revis˜ao dos metadados. A participa¸c˜ao da comunidade, tanto no uso quanto na manuten¸c˜ao da BDBComp, ´e essencial para garantir a sua sustentabilidade [25]. Desta forma, o servi¸co de auto-arquivamento proposto ´e voltado exclusivamente para a comunidade da ´area de computa¸c˜ao e permite somente o auto-arquivamento de publica¸c˜oes do tipo post-prints. O servi¸co de auto-arquivamento da BDBComp, ilustrado na Figura 3.3, ´e um servi¸co com- plexo que compreende trˆes servi¸cos b´asicos: cadastramento, submiss˜ao e revis˜ao [35]. O servi¸co de cadastramento permite que os usu´arios se cadastrem como contribuidores, para que, dessa forma, submetam os metadados de seus trabalhos. O servi¸co de submiss˜ao con- trola todas as submiss˜oes realizadas. O servi¸co de revis˜ao garante a qualidade dos metadados submetidos. No servi¸co de revis˜ao, os revisores analisam os metadados quanto `a sua auten- ticidade, pertinˆencia e qualidade. Todos os servi¸cos se comunicam com o reposit´orio, que armazena metadados dos trabalhos submetidos e dados dos usu´arios envolvidos no processo de submiss˜ao. A comunica¸c˜ao entre os servi¸cos e o reposit´orio ´e realizada atrav´es do proto- colo Java DataBase Connectivity (JDBC).
Os servi¸cos s˜ao utilizados atrav´es da tecnologia cliente-servidor. O cliente, desenvolvido em HTML e JSP (Java Server Pages), ´e a parte visual da aplica¸c˜ao que serve de interface entre os usu´arios e o servi¸co de auto-arquivamento da BDBComp. O servidor, desenvolvido em Java com tecnologia Servlets, ´e onde residem os servi¸cos que constituem o servi¸co de auto-arquivamento e onde ´e realizado o processamento das solicita¸c˜oes dos clientes.
O servi¸co de auto-arquivamento, aqui descrito, foi criado sem o uso de modelos para cons- tru¸c˜ao de servi¸cos em bibliotecas digitais. Todo o estudo de elementos, servi¸cos, comu- nidades, estruturas, interfaces e dados, envolvidos no processo de cria¸c˜ao, foram baseados
nas caracter´ısticas e funcionalidades da BDBComp, sem passar por um processo de mode- lagem formal. Em [35], ´e descrita a prototipa¸c˜ao de um servi¸co de auto-arquivamento para BDBComp utilizando a modelagem formal por meio da abordagem 5S [16, 17] e das ferra- mentas 5SGraph [36] e 5SLGen [22]. Por´em esse servi¸co n˜ao engloba toda a funcionalidade retratada neste trabalho.
Figura 3.3: Arquitetura do servi¸co de auto-arquivamento da BDBComp.