Existem quatro tipos de usu´ario que podem interagir com o servi¸co de auto-arquivamento da BDBComp: usu´ario geral, contribuidor, revisor e administrador. Na Figura 3.3 ´e mostrada a intera¸c˜ao desses usu´arios com os servi¸cos.
O usu´ario geral interage com o servi¸co de cadastramento, a partir do qual fornece dados b´asicos solicitados pela interface para que o seu cadastramento ocorra, tais como, nome, e- mail e institui¸c˜ao. Al´em disso, deve ainda informar um login name e uma senha para poder
utilizar o servi¸co de submiss˜ao. Uma vez cadastrado n˜ao precisar´a mais utilizar o servi¸co de cadastramento ao acessar o servi¸co de submiss˜ao.
O contribuidor ´e o usu´ario que submeter´a os metadados dos trabalhos `a BDBComp, inte- ragindo com o servi¸co de submiss˜ao. Esse usu´ario poder´a submeter qualquer trabalho definido pelo servi¸co, de forma que ele n˜ao precisa ser o autor do trabalho, basta ser au- torizado pelo autor e ter os dados necess´arios para efetuar a submiss˜ao. Qualquer usu´ario comum poder´a ser um contribuidor, basta se cadastrar no servi¸co de cadastramento e auto- arquivar algum trabalho.
O revisor ´e um usu´ario especializado, designado pelo administrador da biblioteca digital, que tem a fun¸c˜ao importante de garantir a qualidade do reposit´orio, pois ´e respons´avel por analisar as submiss˜oes de uma determinada ´area de conhecimento, podendo aceit´a-las ou rejeit´a-las. Um revisor pode tamb´em submeter trabalhos ao servi¸co de submiss˜ao, mas para isso tem que estar cadastrado como um contribuidor.
O administrador ´e o respons´avel por administrar todo o servi¸co de auto-arquivamento, in- teragindo com o banco de dados da BDBComp diretamente. Ele pode excluir, adicionar ou editar qualquer trabalho, assim como, pode tamb´em adicionar ou excluir um determinado contribuidor ou revisor. Ele ´e respons´avel tamb´em pelo cadastramento dos revisores para cada ´area de conhecimento.
3.4
Caracter´ısticas
O servi¸co de auto-arquivamento da BDBComp foi projetado para receber submiss˜oes de diversas ´areas de conhecimento dentro da ciˆencia da computa¸c˜ao. Cada trabalho submetido, obrigatoriamente tem que pertencer a uma ´area de conhecimento, como, por exemplo, bancos de dados e redes de computadores, e ser de um determinado tipo. Os tipos de trabalho aceitos inicialmente pelo servi¸co s˜ao: livros, cap´ıtulos de livro, trabalhos publicados em peri´odicos e trabalhos publicados em anais de eventos. Para cada tipo de trabalho, os metadados informados pelo contribuidor s˜ao diferentes e ser˜ao melhor detalhados nas se¸c˜oes seguintes. Os trabalhos submetidos podem ser encontrados em trˆes estados diferentes, como mostrado na Tabela 3.1.
O servi¸co mant´em em seu reposit´orio informa¸c˜oes de eventos e peri´odicos da ´area da com- puta¸c˜ao. Ao submeter os metadados de um trabalho publicado nesses ve´ıculos, o contribuidor deve selecionar o evento ou peri´odico no qual foi publicado. Na lista fornecida pela interface de submiss˜ao, caso o ve´ıculo (evento ou peri´odico) n˜ao seja encontrado, o usu´ario tem a op¸c˜ao
de inser´ı-lo, informando alguns dados solicitados pela interface. Os dados dos peri´odicos ou eventos submetidos passam tamb´em pelo processo de revis˜ao para serem analisados e depois aceitos ou rejeitados. Caso aceitos, tornam-se dispon´ıveis para as pr´oximas submiss˜oes, caso rejeitados, s˜ao exclu´ıdos do reposit´orio. Neste servi¸co n˜ao ´e submetido o texto eletrˆonico dos trabalhos. Assim, o contribuidor deve informar a URL em que o trabalho se encontra e, a partir dela, o usu´ario ter´a acesso ao texto completo.
Estado Caracter´ıstica
Submetido Aquele que foi submetido e ainda aguarda o processo de revis˜ao.
Aceito Aquele que j´a passou pelo processo de revis˜ao, foi aceito e est´a dispon´ıvel para consulta na biblioteca digital.
Rejeitado Aquele que j´a passou pelo processo de revis˜ao e foi rejeitado.
Tabela 3.1: Estados dos trabalhos submetidos.
Para o contribuidor e revisor terem acesso aos servi¸cos de submiss˜ao e revis˜ao, respectiva- mente, eles devem ser autenticados atrav´es de um login name e senha. A autentica¸c˜ao cria uma sess˜ao para cada indiv´ıduo (contribuidor ou revisor). Para o contribuidor a sess˜ao criada ´e chamada de “´area do contribuidor” e exibe todos os trabalhos submetidos por ele, o estado em que se encontram as suas submiss˜oes e a op¸c˜ao de altera¸c˜ao de seus dados cadastrais. As submiss˜oes que n˜ao estejam no estado “aceito” s˜ao limitadas `a “´area do contribuidor”, ou seja, somente o contribuidor respons´avel por aquela submiss˜ao pode acess´a-las. Para o revisor, a sess˜ao criada ´e chamada de “´area do revisor” e possui uma lista de submiss˜oes de trabalhos, de peri´odicos e de eventos para serem analisados. As submiss˜oes s˜ao analisadas somente por um revisor, ou seja, s˜ao alocadas para uma ´unica “´area de revisor”. No caso do administrador, ele n˜ao precisa ser autenticado para ter acesso aos servi¸cos, pois tem acesso a qualquer submiss˜ao atrav´es de consultas ao banco de dados.
O servi¸co de submiss˜ao garante que os trabalhos repetidos n˜ao sejam inclu´ıdos no reposit´orio. Para isso, realiza um processo de verifica¸c˜ao dos metadados no momento da submiss˜ao do trabalho, assegurando qualidade no conte´udo do reposit´orio e n˜ao redundˆancia de dados. Essa verifica¸c˜ao ´e realizada atrav´es de identificadores individuais que s˜ao armazenados no reposit´orio e criados a partir dos metadados do trabalho. Cada trabalho possui seu identi- ficador individual que identifica unicamente aquele trabalho. No momento da submiss˜ao, o processo de verifica¸c˜ao consulta se existe no reposit´orio algum identificador igual ao que est´a sendo submetido. Caso exista, ou seja, caso o trabalho j´a tenha sido submetido anteriormente por outro contribuidor e tenha sido aceito ou esteja no estado de submetido, a submiss˜ao n˜ao ´e conclu´ıda e, assim, os metadados do trabalho n˜ao s˜ao inclu´ıdos no reposit´orio. Essa verifica¸c˜ao n˜ao considera as submiss˜oes que foram rejeitadas.
O servi¸co de auto-arquivamento suporta algumas fun¸c˜oes de aux´ılio aos usu´arios. Por exem- plo, o servi¸co de submiss˜ao auxilia o contribuidor a ter acesso `a sua ´area do contribuidor caso tenha esquecido seu login name ou senha. Para isso, o contribuidor dever´a informar o seu e-mail j´a previamente cadastrado pelo servi¸co de cadastramento, e o servi¸co envia, via e-mail, sua senha e login name. Existem tamb´em links de ajuda, caso o contribuidor tenha alguma d´uvida no momento do preenchimento do formul´ario de submiss˜ao Al´em disso, a interface de submiss˜ao dispara alertas caso o preenchimento do formul´ario n˜ao tenha sido efetuado corretamente. No servi¸co de revis˜ao, existe uma fun¸c˜ao de notifica¸c˜ao, via e-mail, aos revisores, informando quando um n´umero de dez submiss˜oes foram armazenadas no reposit´orio `a espera de revis˜ao. Essa fun¸c˜ao funciona como um lembrete para que o revisor entre em sua ´area de revis˜ao e fa¸ca a revis˜ao das submiss˜oes que foram alocadas a ele. Caso isso n˜ao aconte¸ca, a cada dez submiss˜oes alocadas ao revisor, a fun¸c˜ao de notifica¸c˜ao ´e disparada.
Outras caracter´ısticas do servi¸co de auto-arquivamento da BDBComp s˜ao descritas com maiores detalhes nas subse¸c˜oes seguintes.
3.4.1
Autoriza¸c˜oes
O servi¸co de auto-arquivamento possui uma pol´ıtica de autoriza¸c˜ao. Assim, para cada usu´ario executar uma a¸c˜ao dever´a possuir permiss˜ao para isso. As a¸c˜oes que o servi¸co autoriza est˜ao descritas na Tabela 3.2.
Qualquer contribuidor possui permiss˜ao de SUBMETER um trabalho `a BDBComp, desde que tenha informa¸c˜oes suficientes para inserir os metadados de um trabalho usando o for- mul´ario da interface do servi¸co de submiss˜ao. O contribuidor tem permiss˜ao de VISU- ALIZAR os metadados de suas submiss˜oes em qualquer estado que estiverem (submetido, aceito ou rejeitado), sendo os metadados mostrados no formato Dublin Core Qualificado. Caso as submiss˜oes estejam no estado de submetido ou rejeitado, o contribuidor poder´a AL- TERAR os metadados e submetˆe-los novamente ou EXCLUIR o trabalho submetido, o que, neste caso, resultar´a na perda de todos os dados de sua submiss˜ao.
O revisor tem permiss˜ao de ACEITAR ou REJEITAR a submiss˜ao de um trabalho ou de peri´odicos e eventos. Essa a¸c˜ao ´e realizada pelo livre arb´ıtrio do revisor, que deve somente rejeitar as submiss˜oes que possuem dados errˆoneos, impertinentes, irreais ou que ser˜ao ar- mazenadas na BDBComp por outros meios.
dados.
A¸c˜ao Caracter´ıstica
SUBMETER A¸c˜ao de adicionar metadados de um trabalho ao reposit´orio da BDBComp.
VISUALIZAR A¸c˜ao de ver os metadados de um trabalho submetidos no formato
Dublin Core. Essa a¸c˜ao deve ser executada dentro da
“´area do contribuidor”para submiss˜oes em qualquer estado. ALTERAR A¸c˜ao de alterar os metadados do trabalho e submetˆe-los
novamente, n˜ao incluindo permiss˜ao para exclus˜ao. Essa a¸c˜ao deve ser executada dentro da ´area de cada contribuidor
para submiss˜oes que estejam no estado de submetido ou rejeitado. EXCLUIR A¸c˜ao de excluir os metadados do trabalho submetido. Essa
a¸c˜ao deve ser executada dentro de cada ´area do contribuidor para submiss˜oes que estejam no estado de submetido ou rejeitado. ACEITAR A¸c˜ao de verificar e aceitar os metadados das submiss˜oes no
formato Dublin Core.
REJEITAR A¸c˜ao de verificar e rejeitar os metadados das submiss˜oes no formato Dublin Core, devido a algum dado errado ou porque o trabalho submetido ser´a armazenado no reposit´orio por outros meios que n˜ao seja o auto-arquivamento.
Tabela 3.2: A¸c˜oes permitidas no servi¸co de auto-arquivamento.
3.4.2
Fluxos de Trabalho
Existe um fluxo de trabalho para cada um dos servi¸cos b´asicos definidos para o servi¸co de auto-arquivamento. Nesta se¸c˜ao s˜ao descritos os fluxos de trabalhos para os servi¸cos de submiss˜ao e de revis˜ao, que envolvem dois tipos de usu´ario, contribuidores e revisores. O servi¸co de submiss˜ao ´e iniciado atrav´es da autentica¸c˜ao do login name e senha para entrada na “´area do contribuidor”. Para iniciar o processo de submiss˜ao, o contribuidor deve clicar no link de submiss˜ao que se encontra dentro da “´area do contribuidor”. O processo de submiss˜ao possui trˆes etapas:
1. O contribuidor seleciona o tipo de trabalho cujos metadados deseja submeter, esco- lhendo entre livro, cap´ıtulo de livro, trabalho publicado em peri´odico e trabalho pu- blicado em anais de evento.
2. O contribuidor insere os dados solicitados pelos campos do formul´ario. Para trabalhos publicados em peri´odicos e em anais de eventos existe uma lista de nomes de eventos e peri´odicos da ´area de ciˆencia da computa¸c˜ao. O contribuidor deve selecionar na lista, antes de informar os dados do trabalho, o evento ou peri´odico no qual o trabalho foi publicado. Caso n˜ao esteja na lista, o contribuidor pode inser´ı-lo, informando, os dados
solicitados. Ap´os informar o evento ou peri´odico, o contribuidor passa para uma nova p´agina Web, para inserir os dados solicitados pelo formul´ario a respeito do trabalho. 3. Ao t´ermino do processo de submiss˜ao, o contribuidor submete os metadados, os quais
s˜ao armazenados no reposit´orio com estado de “submetido”, ou seja, ficar˜ao `a espera de serem analisados e aceitos atrav´es do servi¸co de revis˜ao. No momento da submiss˜ao, o contribuidor seleciona a ´area de conhecimento `a qual o trabalho pertence. Por meio da ´area de conhecimento, o pr´oprio servi¸co de submiss˜ao j´a aloca o trabalho para o revisor daquela ´area. Assim, as submiss˜oes s˜ao distribu´ıdas para cada revisor, conforme sua ´area de conhecimento. O mesmo processo ocorre com os eventos e peri´odicos informados pelo contribuidor no caso deles n˜ao terem sido encontrados na lista de eventos e peri´odicos. Eles ser˜ao alocados para um determinado revisor conforme a ´area de conhecimento. Conclu´ıda a submiss˜ao, tem in´ıcio um processo de verifica¸c˜ao para garantir que os metadados do trabalho ainda n˜ao foram submetidos anteriormente por outro contribuidor. Caso isso aconte¸ca, o servi¸co n˜ao permite que o trabalho seja submetido novamente, mostrando uma p´agina Web ao contribuidor, informando o t´ıtulo do trabalho que j´a foi submetido e a pessoa que o submeteu.
O servi¸co de revis˜ao ´e iniciado pela autentica¸c˜ao do login name e senha para entrada na “´area do revisor”. O revisor possui na sua ´area uma lista de trabalhos e nomes de eventos e peri´odicos para serem aprovados, e cada submiss˜ao passa por uma ´unica revis˜ao. O processo possui trˆes etapas:
1. O revisor clica no link de revis˜ao para analisar os metadados dos trabalhos submetidos e alocados para ele. Na p´agina Web de revis˜ao do trabalho, existe uma lista com os campos no formato Dublin Core Qualificado e metadados administrativos do trabalho. O revisor deve analisar os dados verificando-os quanto a autenticidade, pertinˆencia e qualidade.
2. Caso o revisor n˜ao encontre dados errˆoneos, deve aceitar a submiss˜ao dos metadados do trabalho simplesmente clicando no link “aprovar”. Isso altera o estado da submiss˜ao de “submetido” para “aceito”, permitindo que os metadados do trabalho que foram aceitos possam ser visualizados por qualquer usu´ario que consultar a BDBComp poste- riormente. Caso o revisor rejeite a submiss˜ao, clicando no link “reprovar”, o estado da submiss˜ao ´e alterado de “submetido” para “rejeitado”, limitando, assim, a visualiza¸c˜ao dos metadados do trabalho somente para o contribuidor daquele trabalho, que pode alter´a-los e submetˆe-los novamente, reiniciando o processo de revis˜ao. O revisor pode enviar tamb´em um e-mail para o contribuidor do trabalho informando o motivo da rejei¸c˜ao.
3. No caso da revis˜ao de eventos e peri´odicos, o revisor verifica o nome do evento e do peri´odico, e, respectivamente, a sigla e o ISSN. Caso aceite, o peri´odico ou evento ´e armazenado no reposit´orio para posterior consulta no momento da submiss˜ao de um trabalho publicado nesses meios. Caso o revisor rejeite a submiss˜ao, o evento ou peri´odico ´e exclu´ıdo.
3.5
Reposit´orio de Metadados
O reposit´orio criado para atender o servi¸co de auto-arquivamento ´e baseado no reposit´orio de metadados da BDBComp. ´E um banco de dados relacional que foi implementado em MySQL de acordo com o esquema representado pelo diagrama ER da Figura 3.4.
Figura 3.4: Esquema do reposit´orio do servi¸co de auto-arquivamento da BDBComp. O esquema suporta o armazenamento de metadados de livros, cap´ıtulos de livro, trabalhos
publicados em eventos e trabalhos publicados em peri´odicos, al´em de armazenar dados sobre os contribuidores e revisores. O esquema foi projetado para criar um banco de dados mais eficiente do que o banco de dados que implementa o reposit´orio original da BDBComp. Como no reposit´orio da BDBComp [25], o esquema mostrado na Figura 3.4 tamb´em possui um tipo de entidade work que representa os trabalhos armazenados no reposit´orio e possui alguns atributos multivalorados e outros monovalorados. O esquema atende ao formato Dublin Core Qualificado, e os atributos da entidade work correspondem aos elementos desse formato. Como pode ser percebido, o esquema mostrado na Figura 3.2 possui, para o tipo de entidade work , alguns atributos multivalorados que foram definidos como atribu- tos monovalorados no esquema do reposit´orio do servi¸co de auto-arquivamento, mostrado na Figura 3.4. Isso ocorre pois foi verificado que, na pr´atica, para os tipos de trabalho armazenados na BDBComp, alguns atributos possuem um ´unico valor (por exemplo, title, date, language, coverage, publisher e type). Assim, essa altera¸c˜ao melhora o desempenho do servi¸co facilitando o acesso ao reposit´orio.
No esquema existem os tipos de entidade revisor e contribuidor que descrevem os dados pessoais respectivamente dos revisores e contribuidores do servi¸co de auto-arquivamento. O tipo de entidade area caracteriza a ´area de conhecimento dos trabalhos e relaciona cada trabalho com um revisor, de acordo com a ´area de conhecimento dos revisores. Para cada ´area de conhecimento existe um revisor. O tipo de entidade meio publica¸c˜ao representa os eventos e peri´odicos da ´area de ciˆencia da computa¸c˜ao e possui, al´em da chave-prim´aria, atributos, tais como, name, identifier (sigla do evento ou ISSN), typedocs (representa o evento ou peri´odico) e status. Este ´ultimo atributo identifica o meio de publica¸c˜ao como aceito pelo processo de revis˜ao ou `a espera do processo de revis˜ao. O tipo de entidade meio publica¸c˜ao est´a relacionado com o tipo de entidade revisor para garantir que um revisor analise os dados dos eventos e peri´odicos. Os eventos e peri´odicos armazenados no reposit´orio foram retirados da base de dados do Qualis da CAPES (http://qualis.capes.gov.br/) e da DBLP (http://www.informatik.uni-trier.de/ ley/db), tendo sido realizada uma triagem nessas bases de dados para selecionar os eventos e peri´odicos nos quais os pesquisadores brasileiros mais publicam.
Uma das caracter´ısticas do reposit´orio de metadados ´e a compatibilidade com o protocolo OAI-PMH. Para isso, o padr˜ao OAI adiciona alguns campos, al´em dos utilizados no Dublin Core, formando um registro de cada documento armazenado no provedor de dados [44]. Para entender melhor o formato do registro OAI que o reposit´orio suporta, a Figura 3.5 mostra o formato XML de um registro desse tipo. O registro ´e constitu´ıdo de trˆes partes:
de cria¸c˜ao ou ´ultima altera¸c˜ao do documento associado a este registro; ´e a chave que permite a coleta autom´atica dos metadados a partir de uma determinada data. Possui tamb´em um campo de identifica¸c˜ao ´unico, chamado identifier, e um campo chamado setspec, que relaciona cada trabalho com um determinado conjunto. Esse campo ´e representado pelo tipo de entidade set.
2. metadata, que possui os campos no formato Dublin Core Qualificado.
3. about, que possui o campo provenance para identificar a procedˆencia do registro.
< record > < header >
< identif ier > issn0169-023XYEAR2002VOL40NUM2metaPAG121154 < /identif ier > < datestamp > 2004-11-10 < /datestamp >
< setspec > bdbcomp:periodicos art ind < /setspec > < /header >
< metadata > < oai dc : dc >
< dc : title > DEByE - DataExtraction By Example < /dc : title > < dc : creator > Alberto H. F. Laender < /dc : creator >
< dc : creator > Berthier Ribeiro-Neto < /dc : creator > < dc : creator > Altigran S. da Silva < /dc : creator > < dc : subject > Data extraction < /dc : subject > < dc : subject > Wrapper generation < /dc : subject > < dc : subject > Web data management < /dc : subject >
< dc : description > In this paper we present DEByE (Data Extraction By Example),
an approach to extracting data from Web sources ... as demonstrated by our experiments. < /dc : description >
< dc : publisher > Elsevier Science B.V. < /dc : publisher > < dc : contributor >< /dc : contributor >
< dc : date > 2002 < /dc : date > < dc : type > Text < /dc : type >
< dc : f ormat > application/pdf < /dc : f ormat >
< dc : identif ier > issn0169-023XYEAR2002VOL40NUM2PAG121154 < /dc : identif ier > < dc : identif ier > http://www.sciencedirect.com/science298302.pdf < /dc : identif ier > < dc : identif ier >
< dc : terms : bibliographicCitation >
JounalTitle=Data & Knowledge Engineering; JournalIdentifier=0169-023X; Volume=40; IssueNumber=2; IssueDate=February; Pagination=121-154