1. Patrocinadores Platina
Patrocinadores Ouro
Patrocinadores Prata Apoios Organização
Workshop - Repositórios Integrados
José Carvalho - jcarvalho@sdum.uminho.pt
Paulo Lopes - plopes@fccn.pt
Pedro Príncipe - pedroprincipe@sdum.uminho.pt
2. Agenda
1. Integração entre Sistemas - 15 min
a. Depósito a partir de entidades externas - 15 min
2. Dashboard OpenAIRE - 30 min
3. Broker OpenAIRE - 30 min
3. Agenda
1. Integração entre Sistemas
a. Depósito a partir de entidades externas
2. Dashboard OpenAIRE
3. Broker OpenAIRE
5. Integração de Sistemas
Porquê?
Necessidade de automatizar processos, fluxos de informação,...
Como?
Uniformização de metadados, guidelines, protocolos, processos
O quê?
Interligando sistemas que possam criar valor acrescentado à informação e utilizadores.
8. Nova Ação nos Repositórios
Geralmente, nos repositórios institucionais, os trabalhos são depositados, eventualmente
validados ou revistos e disponibilizados publicamente. Raramente são alterados!
Caminhamos para cada vez mais os os registos adquirirem mais dinâmica.
9. Nova Ação nos Repositórios
Atualização
Enriquecimento de informação
baseado noutros sistemas ou
serviços!
Disponibilização pública
Disponibilização e atribuição de
handle ao trabalho, disseminação
(Portal RCAAP, Google Scholar,... )
Validação
Validação institucional ou da
unidade.
Submissão
Submissão pelo autor, mediado
ou por outro sistema.
11. Agenda
1. Integração entre Sistemas
a. Depósito a partir de entidades externas
2. Dashboard OpenAIRE
3. Broker OpenAIRE
12. Integrações - Porquê?
Maximizar a prática do acesso aberto fornecendo serviços eletrónicos apelativos,
interoperáveis e inovadores
Aumentar a visibilidade da produção científica
Facilitar os processos de depósito e de circulação da informação:
“Add once, reuse multiple times”
17. Benefícios
Circulação da informação
Simplificação dos fluxos de trabalho das instituições
Simplificação do fluxo de trabalho dos investigadores / autores
Aumento de visibilidade da produção científica
...
20. Descrição geral da funcionalidade
Um utilizador do CV deve poder optar por enviar para o repositório documentos
inseridos manualmente ou importados de outras fontes (ORCID, SCOPUS;
WoS,...) que não se encontrem depositados.
21. Requisitos associados à funcionalidade
A interface do CV deve permitir esta ação;
O CV deve ser capaz de identificar o que já está depositado e o que é passível de enviar
para o repositório;
O CV deve proporcionar um wizard associado ao processo de depósito
O CV deverá ser capaz de manter um estado dos documentos enviados para depósito
(Depositado; Recusado; Depósito em processo de aprovação)
22. Passos do depósito
O processo de depósito envolve os seguintes passos:
● Seleção dos itens a enviar para o repositório;
● Seleção do repositório de destino;
● Autenticação;
● Seleção da coleção de destino;
● Preenchimento da informação obrigatória e anexação do ficheiro com o texto
integral do artigo
● Visualização e aceitação da licença associada ao depósito
● Revisão da informação introduzida e remessa para depósito
23. Implementação
Requisito Descrição
RF-01 Seleção do repositório
RF-02 Autenticação
RF-03 Seleção da coleção
RF-04 Upload do ficheiro
RF-05 Aceitação da licença
RF-06 Remessa do depósito
Requisitos funcionais identificados / passos do depósito
24. Requisito prévio - Recursos a depositar
Devem ficar marcadas como depositadas no RCAAP:
● Todas as produções previamente importadas do RCAAP;
● Todas as produções importadas de outros locais (ORCID, SCOPUS, …) que
possuam um identificador handle associado a um dos repositórios da rede
RCAAP
Passando o rato sobre a informação “Depositado no RCAAP” aparece informação
de contexto a identificar o repositório associado aquela publicação
25. Implementação
Requisito Descrição
RF-01 Seleção do repositório
RF-02 Autenticação
RF-03 Seleção da coleção
RF-04 Upload do ficheiro
RF-05 Aceitação da licença
RF-06 Remessa do depósito
Requisitos funcionais identificados / passos do depósito
26. Requisito 1 - Seleção do repositório
A seleção do repositório é facilitada apresentando ao utilizador uma lista restrita
de escolha baseada nos seguintes critérios:
● Com base na informação de afiliação do utilizador associada ao seu perfil CV
(endereço de mail / afiliação);
● Por informação de identificadores “Handle” de informação já importada
previamente do RCAAP. Por exemplo, no handle
http://hdl.handle.net/10316/26135 - o prefixo 10316 pertence ao repositório
da Universidade de Coimbra
27. Implementação
Requisito Descrição
RF-01 Seleção do repositório
RF-02 Autenticação
RF-03 Seleção da coleção
RF-04 Upload do ficheiro
RF-05 Aceitação da licença
RF-06 Remessa do depósito
Requisitos funcionais identificados / passos do depósito
28. Requisito 2 - Autenticação
Pretende-se que a autenticação seja feita de forma transparente para o utilizador
ou com o mínimo de interação por parte deste. Estão previstas as seguintes
possibilidades:
● Single Sign On através do cID. A conta cID é relacionada com a conta local e
o utilizador fica automaticamente ligado e autenticado no Repositório;
● Por associação a conta local (RI) - Para os casos em que as credenciais cID
não foram validadas mas o utilizador conhece o seu login no Repositório;
● Por criação de conta local e associação automática - Para os casos em que
as 2 condições anteriores não se verificam. É criada uma conta local que fica
com permissões para depósito numa única coleção genérica. O gestor do RI
é notificado para validar o utilizador e atribuir-lhe as permissões corretas
(para futuras utilizações)
29. Implementação
Requisito Descrição
RF-01 Seleção do repositório
RF-02 Autenticação
RF-03 Seleção da coleção
RF-04 Upload do ficheiro
RF-05 Aceitação da licença
RF-06 Remessa do depósito
Requisitos funcionais identificados / passos do depósito
30. Requisito 3 - Seleção da coleção
● Com base na autorização do utilizador na conta local do RI. O utilizador
deverá ver uma lista com essas coleções onde terá a possibilidade de
escolher uma.
● No caso de no processo de autenticação ter sido criada uma nova conta é
necessário garantir que existe uma coleção “default” para se efetuar o
depósito ou então garantir direitos de depósito através da afiliação. Da
mesma forma do que no ponto anterior, o utilizador deverá ver uma lista com
a coleção onde pode depositar, que neste caso será uma apenas.
31. Tecnologia de desenvolvimento
SWORD V2 Não suporta autenticação federada
● Necessita utilizador e coleção genérica
● Necessita de validação do depósito
API Suporta autenticação federada
● SSO via Ciência ID
● Escolha da coleção baseada no perfil do
utilizador
32. C1 - SWORD
Desvantagens Vantagens
● Não tira partido da plataforma de
autenticação ciência ID
● Qualquer utilizador poderá efetuar um
depósito bastando-lhe escolher um
repositório de destino
● Não suporta a utilização de identificadores
de autores (embora esta informação possa
ser passada juntamente com o depósito
para introdução posterior)
● Representa um acréscimo de trabalho
para o gestor do repositório que terá de
validar o depósito, colocá-lo na coleção
correta e enriquecer os metadados
(identificador de autor)
● Imediatismo da solução face aos
constrangimentos existentes
● O upgrade para o cenário 2 não deverá
provocar para o utilizador uma disrupção
da funcionalidade em si
● É uma solução amplamente suportada nas
várias versões do DSpace e poderá ser
usada em alternativa REST, ou quando
esta interface não está disponível
33. C2 - REST API (Dspace 7)
Desvantagens Vantagens
● Disponibilização tardia da solução
● Obriga a uma uniformização por
parte dos repositórios em termos
de utilização de nomes de
entidades, campos
● Responderá ao grau de
automatismo e simplificação que
se pretende para o processo de
depósito a partir de outros
sistemas CRIS
● Trará suporte nativo para
identificadores das diversas
entidades (autores, organizações,
financiamento)
● Centra o processo no utilizador e
não no gestor do repositório
36. Como funciona o SWORD?
Dois passos:
Pedido à interface Sword do repositório para se descrever ela própria;
GET https://[hostname]/swordv2/servicedocument
Usa essa informação para preparar e efetuar o depósito
POST https://[hostname]/swordv2/collection/[handle]
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51. Tarefa do Gestor
Validar o depósito;
Acrescentar informação sobre identificador de autor (recomendável);
Mover o depósito para a coleção correta.
Nota: A tarefa de validação atribui o identificador Handle ao recurso. O CV utiliza esta
informação para mudar o estado do recurso: