|
|
| (93 edições intermediárias de um usuário não apresentadas) |
| Linha 1: |
Linha 1: |
| − | == Comunidades, Coleções e Itens ==
| + | A administração de um repositório consiste em um conjunto de procedimentos |
| | + | necessários para o seu pleno funcionamento. A maioria desses procedimentos são feitos |
| | + | diretamente nas páginas do DSpace. Em raros casos, será necessária a intervenção da equipe |
| | + | de informática, com orientação do administrador, para executar algum procedimento mais |
| | + | técnico. Assim, serão abordados os procedimentos executados diretamente no DSpace |
| | + | pelo administrador. Mais além, serão abordados outros procedimentos. |
| | | | |
| − | A estrutura informacional do DSpace, pelo qual o acervo do repositório é disponibilizado, é hierárquico, composto por comunidades, coleções e Itens. Essa estrutura não | + | A administração implica em gerenciar os principais processos no repositório, o que |
| − | apenas permite a organização de acervo, mas também, facilita a recuperação dos objetos
| + | envolve, na maioria dos casos, a recuperação e submissão de itens. Algumas das tarefas |
| − | digitais depositados. Assim, fornecendo uma estrutura que, apesar de rígida, é muito própria
| + | são mais evidentes na implantação do repositório, enquanto outras são constantes durante |
| − | para manter os objetos digitais de forma fácil de construir e manter.
| + | toda a sua existência. Em grande parte, as tarefas do administrador têm relação estreita |
| | + | com as políticas correspondentes a esse repositório. |
| | | | |
| − | === Comunidades e subcomunidades ===
| + | Os procedimentos que são executados diretamente nas páginas do DSpace, de |
| − | As '''comunidades''' e '''subcomunidades''' são estruturas informacionais que representam a organização do repositório. As comunidades são as estruturas de mais alto nível e podem conter vários níveis de subcomunidades. Assim, representam apenas a estrutura,
| + | responsabilidade do administrador, envolvem três conjuntos principais de atividades: |
| − | não contendo objetos digitais diretamente.
| + | |
| | | | |
| − | === Coleções ===
| + | * contexto; |
| − | Os documentos são agrupados nas '''coleções''', e
| + | |
| − | as comunidades, por sua vez, agrupam subcomunidades e coleções.
| + | |
| − | Nesse contexto, as comunidades e subcomunidades podem representar temas ou
| + | |
| − | estruturas organizacionais. Por exemplo, em um repositório institucional de uma universidade, organizado pela estrutura organizacional, as comunidades podem representar as
| + | |
| − | faculdades e institutos, enquanto as subcomunidades representam os departamentos. Por
| + | |
| − | outro lado, se organizado por tema, as comunidades poderiam representar os grandes
| + | |
| − | temas, enquanto as subcomunidade refinariam esses temas em subtemas.
| + | |
| − | Não havendo limites para os níveis de subcomunidades, pode-se refinar os
| + | |
| − | tópicos em árvores que organizem o repositório. Nesse caso, a raiz é a comunidade e
| + | |
| − | os troncos e galhos as subcomunidades. É possível criar quantas comunidades forem
| + | |
| − | necessárias para representar a abrangência do acervo, e em cada comunidade pode-se
| + | |
| − | criar tantas subcomunidades, em vários níveis, quantas forem necessárias para refinar
| + | |
| − | essa comunidade.
| + | |
| | | | |
| − | As coleções são estruturas que servem, preferencialmente, para agrupar documentos com alguma característica comum. Toda coleção deve pertencer a uma comunidade
| + | * controle de acesso e; |
| − | ou subcomunidade, pois enquanto as comunidades organizam o repositório, as coleções
| + | |
| − | organizam os documentos do acervo.
| + | |
| | | | |
| − | === Item ===
| + | * registros. |
| | | | |
| − | Um '''Item''', por sua vez, é um conjunto de descrições e objetos digitais. Pode-se
| + | Todos esses procedimentos necessitam do privilégio de administrador, sendo que essas opções não são apresentadas a outros usuários, pois |
| − | dizer que é a unidade informacional do DSpace. consiste de vários campos descritivos
| + | os menus são dinâmicos. |
| − | aliados aos objetos digitais, que unidos formam uma unidade. Os Itens são depositados
| + | |
| − | nas coleções, que por sua vez, estão contidas nas comunidades e subscomunidades,
| + | |
| − | formando a estrutura do DSpace.
| + | |
| − | Um Item, necessariamente, possui mais que um objeto digital.
| + | |
| | | | |
| − | ==== Tipo, ou formato de arquivo ==== | + | == [[Comunidades, Coleções e Itens]] == |
| − | É comum que as coleções sejam por '''tipo de arquivo''' ou '''formato'''. Assim, coleções
| + | |
| − | de artigos de periódicos ou capítulos de livros são exemplos de coleções organizadas por
| + | |
| − | tipo de arquivo. Já a coleções de vídeo ou áudio, por sua vez, se aplica a organização por
| + | |
| − | formato de arquivo. Não é aconselhável ter coleções que indicam assunto, pois possivelmente iriam se misturar tipos e formatos de arquivos. As comunidades ou subcomunidades
| + | |
| − | são mais apropriadas para representar assuntos.
| + | |
| | | | |
| − | ==== Licença ==== | + | == [[Fluxo de submissão]] == |
| | | | |
| − | No DSpace, ao depositar um documento, é preciso que se aceite uma '''licença'''. Nesse caso, o arquivo textual
| + | == [[Usuários e grupos]] == |
| − | da licença é guardado juntamente com o documento depositado. Esse conjunto de objetos
| + | |
| − | digitais, mais o objeto digital, é denominado de '''bundle'''. Isso garante que o documento
| + | |
| − | depositado permaneça intimamente relacionado à licença concedida.
| + | |
| | | | |
| − | ==== Esquema de metadados ==== | + | == [[Administradores]] == |
| | | | |
| − | A descrição do Item depende dos campos selecionados. O '''esquema de metadados'''
| + | == [[Gerenciar a estrutura informacional do repositório]] == |
| − | padrão do DSpace é o Dublin Core, mas o DSpace permite que se escolha outro esquema,
| + | |
| − | desde que sejam feitas todas as definições. Esses campos servem para descrever os objetos digitais a serem depositados, portando, pode ser definidos conforme a necessidade
| + | |
| − | de descrição.
| + | |
| − | | + | |
| − | == Fluxo de submissão == | + | |
| − | | + | |
| − | O '''fluxo de submissão''' é o processo pelo qual um objeto digital é depositado, percorrendo todas as etapas necessárias dede o início da submissão até que o item esteja
| + | |
| − | disponível para acesso. No DSpace, o fluxo de submissão foi influenciado pelos princípios
| + | |
| − | da comunicação científica, que consiste no processo de avaliação dos registros antes da
| + | |
| − | publicação. Esse processo consiste das etapas de catalogação, avaliação e revisão de
| + | |
| − | metadados. O fluxo de submissão é importante por controlar os Itens que farão parte do
| + | |
| − | acervo do repositório.
| + | |
| − | O fluxo de submissão é ajustado conforme as necessidades da coleção. Dessa forma,
| + | |
| − | não existe apenas uma possibilidade de implementação desse fluxo. Ele é composto de três
| + | |
| − | etapas distintas e que podem ser coordenadas. Das três, apenas a etapa de catalogação é
| + | |
| − | obrigatória. As etapas de avaliação e revisão de metadados são opcionais e podem ou não
| + | |
| − | constituir o fluxo de submissão das coleções.
| + | |
| − | Pode-se escolher o fluxo de submissão adequado a cada comunidade. Por exemplo,
| + | |
| − | para um fluxo que consiste apenas da etapa de catalogação, seria adequado a coleções
| + | |
| − | que não necessitem de avaliação nem revisão de metadados. Assim, bastaria catalogar
| + | |
| − | um Item para que esse possa ser acessado pelos usuários, sem passar por outras etapas.
| + | |
| − | Esse fluxo é recomendado para coleções as quais os depositantes tenham domínio sobre
| + | |
| − | os descritores e os itens não necessitem de avaliação.
| + | |
| − | Para coleções que necessitam de avaliação de pertinência, por exemplo, pode-se
| + | |
| − | escolher um fluxo de submissão que tenha as etapas de catalogação e avaliação. Nesse
| + | |
| − | caso, na etapa de avaliação verifica-se se o item está condizente com a coleção, podendo
| + | |
| − | o mesmo ser aceito ou rejeitado. Assim, o Item só estará disponível para acesso depois de
| + | |
| − | passar pela etapa de avaliação.
| + | |
| − | Em algumas coleções é necessário que se tenha apenas duas etapas, a de catalogação e a de revisão de metadados. Os metadados são importantes para a recuperação de objetos digitais, principalmente os não textuais. Por isso, muitas vezes é necessário que se
| + | |
| − | revise os descritores para melhorá-los de forma a facilitar a recuperação. Em outros casos,
| + | |
| − | isso serviria para ajustar a terminologia, pois alguns repositórios requerem uniformidade
| + | |
| − | de discurso.
| + | |
| − | | + | |
| − | === Etapas do fluxo de submissão ===
| + | |
| − | | + | |
| − | O '''fluxo de submissão''' composto pelas três '''etapas''' é o mais adequado para as coleções
| + | |
| − | que necessitam de maior controle sobre os itens. Esse fluxo de submissão, consistindo das
| + | |
| − | três etapas, impõe que um Item, para constar no acervo, tenha que ser avaliado e ter revisado
| + | |
| − | os seus metadados. Nesse caso, passa pelo processo de avaliação, com possibilidade de
| + | |
| − | rejeição e revisão das informações preenchidas no processo de catalogação.
| + | |
| − | | + | |
| − | As etapas que compõe o fluxo de submissão devem ser executadas por usuários
| + | |
| − | com perfis diferenciados, sendo que apenas a catalogação pode ter um grupo de usuários
| + | |
| − | mais amplo. Entretanto, a avaliação e revisão de metadados devem ser executadas por
| + | |
| − | usuários com conhecimento específico para a realização dessas tarefas.
| + | |
| − | | + | |
| − | [[Arquivo:Submissao.png|center|900px]] | + | |
| − | | + | |
| − | ==== Catalogação ====
| + | |
| − | | + | |
| − | A catalogação consiste na etapa pela qual se descreve e carrega o objeto digital
| + | |
| − | no repositório. Essa etapa possui cinco passos. Inicia respondendo as questões iniciais,
| + | |
| − | passando pelo preenchimento do formulário de entrada, carga do objeto digital, aceite da
| + | |
| − | licença e, finalmente, visualização de todos os passos. Ao término desses passos, o item
| + | |
| − | estará pendente se o fluxo consistir de mais passos. caso contrário, estará disponível para
| + | |
| − | acesso.
| + | |
| − | | + | |
| − | Quando executada pelo próprio autor recebe o nome de autoarquivamento. Isso facilita, no que concerne aos direitos autorais, o aceite da licença. Entretanto, na maioria dos casos, a catalogação é feita por terceiros que possuem direitos de depósito.
| + | |
| − | Independentemente do usuário que execute a catalogação, iniciando o fluxo de submissão,
| + | |
| − | o fato de um documento estar depositado no repositório não significa, necessariamente,
| + | |
| − | que o mesmo está disponível. O acesso aos documentos depende das políticas de acesso
| + | |
| − | e dos direitos de disseminação do repositório.
| + | |
| − | | + | |
| − | ==== Avaliação ====
| + | |
| − | | + | |
| − | A avaliação consiste em verificar se o item catalogado está compatível com a coleção.
| + | |
| − | Nesse caso, há apenas duas opções: aceitar ou rejeitar. Ao ser aceito, o Item passa para
| + | |
| − | a próxima etapa do fluxo; se não houver a etapa de revisão de metadados, o item estará
| + | |
| − | disponível para acesso. caso haja a rejeição, é necessário justificar. Então, um e-mail
| + | |
| − | automático com a justificativa é enviado ao autor.
| + | |
| − | | + | |
| − | ==== Revisão de metadados ====
| + | |
| − | | + | |
| − | A revisão de metadados não tem a capacidade de rejeitar um item, faz apenas ajustar
| + | |
| − | ou corrigir as informações fornecidas durante o processo de catalogação. Essa etapa tem
| + | |
| − | grande influência na recuperação de um Item, principalmente de objetos não textuais, que
| + | |
| − | necessitam dos metadados para o processo de busca. Objetos digitais textuais podem ter
| + | |
| − | o texto completo indexado para facilitar a recuperação.
| + | |
| − | | + | |
| − | == Usuários e grupos ==
| + | |
| − | | + | |
| − | O DSpace organiza-se com usuários e grupos para gerenciar, entre outros, as permissões para executar tarefas no repositório. Entre essas permissões estão as relacionadas ao
| + | |
| − | acesso e fluxo de submissão, acesso aos objetos digitais e gerenciamento do repositório.
| + | |
| − | Essa organização visa facilitar o gerenciamento tanto das pessoas que acessam o repositório
| + | |
| − | quanto dos acessos aos recursos depositados.
| + | |
| − | | + | |
| − | Toda pessoa que acessa o DSpace, independente da operação, é um usuário. Nesse
| + | |
| − | sentido pode-se dividir os usuários em dois grupos, daqueles que possuem cadastro no
| + | |
| − | DSpace e dos que não possuem. Os usuários que não possuem cadastro podem ser denominados leitores e tem menor relação com as permissões de acesso. Os usuários cadastrados
| + | |
| − | podem ser divididos conforme as permissões, constituindo grupos de administradores,
| + | |
| − | catalogadores, avaliadores e outros.
| + | |
| − | | + | |
| − | Há algumas formas de um usuário ter um cadastro no DSpace. O autocadastramento
| + | |
| − | e o cadastramento pelo administrador são as duas formas mais comuns. Independente
| + | |
| − | da forma de cadastramento, os usuários cadastrados possuem registro no DSpace e sua
| + | |
| − | identificação é um endereço de e-mail. Essa opção deve-se ao fato de que o DSpace se
| + | |
| − | comunica com seus usuários através de mensagens eletrônicas automáticas.
| + | |
| − | | + | |
| − | O autocadastramento é uma opção de cadastramento que o administrador ou o
| + | |
| − | grupo gestor do repositório deve decidir se mantém ou não, pois ela permite que um usuário
| + | |
| − | possa criar seu registro no repositório sem o intermédio do administrador. Por outro lado,
| + | |
| − | o cadastramento dos usuários pelo administrador permite um controle maior do processo
| + | |
| − | de cadastramento, pois requer a intervenção do administrador para que um usuário se
| + | |
| − | cadastre no repositório.
| + | |
| − | | + | |
| − | Seja qual for a forma de cadastramento, no que diz respeito ao gerenciamento dos
| + | |
| − | usuários, o administrador é quem delega os privilégios, concedendo-os diretamente aos
| + | |
| − | usuários ou conectando-os a um grupo que possui as permissões desejadas, necessárias
| + | |
| − | para executar as tarefas. Entretanto, nem todo usuário precisa ter permissões, dependendo
| + | |
| − | das políticas de acesso aos recursos do repositório.
| + | |
| − | | + | |
| − | O administrador ou grupo gestor do repositório pode restringir todo o acervo do repositório. Dessa forma, é necessário o cadastramento para ter acesso aos objetos digitais depositados. Por outro lado, pode-se permitir acesso aberto a parte do acervo ou a sua totalidade,
| + | |
| − | permitindo que usuários sem cadastramento acessem os objetos digitais depositados.
| + | |
| − | | + | |
| − | Para reunir usuários que possuem privilégios semelhantes, o DSpace, permite que
| + | |
| − | eles sejam organizados em grupos. Assim, ao invés de delegar privilégios diretamente aos
| + | |
| − | usuários, delega-se privilégios aos grupos. Dessa forma, os usuários conectados a esses
| + | |
| − | grupos recebem os respectivos privilégios. Um usuário conectado a vários grupos agrega
| + | |
| − | os privilégios de todos eles. Os grupos também podem conter outros grupos, facilitando o
| + | |
| − | gerenciamento das permissões concedidas.
| + | |
| − | | + | |
| − | O DSpace possui dois grupos padrão, criados na instalação: o grupo de anônimos e
| + | |
| − | o grupo de administradores. Enquanto o grupo de anônimos não possui nenhum privilégio
| + | |
| − | dentro do repositório, a não ser que o administrador lhe conceda, o grupo de administradores
| + | |
| − | possui todos os privilégios. Desse modo, os grupos de privilégios intermediários devem ser
| + | |
| − | criados pelo administrador.
| + | |
| − | | + | |
| − | Todo usuário que acessa o DSpace e não se identifica é automaticamente conectado
| + | |
| − | ao grupo de anônimos. Portanto, em um repositório de acervo aberto, um usuário leitor,
| + | |
| − | ao acessar um objeto digital, o faz como se pertencesse ao grupo de anônimos. Deve-se,
| + | |
| − | no entanto, retirar o acesso desse grupo se houver necessidade de restringir o acesso a um
| + | |
| − | objeto digital, coleção ou comunidade.
| + | |
| − | | + | |
| − | O grupo de administradores reúne os usuários que possuem todos os privilégios no
| + | |
| − | repositório, inclusive o de simular outros usuários para corrigir problemas. Nesse caso, não
| + | |
| − | é preciso conceder privilégios a esse grupo, pois mesmo que não conste na lista de grupos
| + | |
| − | com privilégios, ele os possui.
| + | |
| − | | + | |
| − | Outros grupos são criados automaticamente, dependendo da ação executada. Por
| + | |
| − | exemplo, ao optar por um fluxo de submissão na criação de uma coleção, grupos são criados para reunir os usuários que possam executar determinados passos. Esses grupos terão
| + | |
| − | nomes relacionados à coleção e ao passo para o qual está sendo concedida a permissão.
| + | |
| − | | + | |
| − | == Administradores ==
| + | |
| − | | + | |
| − | Os administradores são os usuários importantes para o funcionamento do
| + | |
| − | repositório. cabe a eles garantir aos outros usuários a disponibilidade adequada das ferramentas e informações do repositório. A função de administrador, mesmo que possa ser
| + | |
| − | compartilhada ou dividida, é vital para o funcionamento do repositório.
| + | |
| − | | + | |
| − | Para facilitar a administração do repositório, pode-se criar '''administradores''' para
| + | |
| − | as comunidades ou subcomunidades. Esses administradores gerenciam vários aspectos
| + | |
| − | das comunidades e subcomunidades, dividindo assim a responsabilidade e facilitando o
| + | |
| − | gerenciamento de repositórios muito grandes. Essa facilidade é opcional mas muito útil,
| + | |
| − | dependendo da organização do repositório.
| + | |
| − | | + | |
| − | As coleções também podem ter administradores. Esses usuários, com permissões
| + | |
| − | especiais, podem controlar aspectos da coleção e itens que estão contidos nela. Dessa
| + | |
| − | forma, pode-se distribuir as responsabilidades em diversos níveis, se for preciso. Os administradores das coleções podem controlar os acessos aos itens, por exemplo, se houver
| + | |
| − | algum tipo de restrição de acesso.
| + | |
| − | | + | |
| − | === Administrador do repositório ===
| + | |
| − | | + | |
| − | Os administradores são os profissionais que gerenciam o funcionamento do repositório. Atuando diretamente nos procedimentos do repositório, são responsáveis por
| + | |
| − | mantê-lo ajustado aos propósitos da instituição mantenedora. Para que isso ocorra, necessitam interagir com vários tipos de usuários, dos técnicos de informática aos usuários que
| + | |
| − | acessam o repositório em busca de informação.
| + | |
| − | | + | |
| − | Devido à grande responsabilidade em que isso acarreta, recomenda-se que haja mais
| + | |
| − | de um usuário com privilégios de administrador, proporcionando assim maior segurança e disponibilidade dos seus serviços. O compartilhamento de administradores requer cuidados, mas
| + | |
| − | garante a continuidade do atendimento em caso de ausência de um dos administradores.
| + | |
| − | | + | |
| − | Os administradores do repositório, portanto, possuem todos os privilégios no repositório, podendo
| + | |
| − | executar todos os procedimentos disponíveis. Nesse caso podem, inclusive, executar tarefas
| + | |
| − | destinadas a outros tipos de usuários. Esse procedimento muitas vezes é utilizado para
| + | |
| − | solucionar problemas. Assim, o administrador possui a facilidade de simular qualquer outro
| + | |
| − | usuário no repositório.
| + | |
| − | | + | |
| − | As tarefas dos administradores requerem conhecimentos específicos do DSpace,
| + | |
| − | sobre os quais será tratado nesse guia. Entretanto, há outros conhecimentos, mais gerais,
| + | |
| − | relacionados à disseminação, recuperação e organização da informação, por exemplo, que
| + | |
| − | também são necessários, mas não obrigatórios. De qualquer modo, o administrador deve
| + | |
| − | estar alinhado aos propósitos da instituição em relação ao repositório.
| + | |
| − | | + | |
| − | ==== Tarefas do administrador do repositório ====
| + | |
| − | | + | |
| − | A principal tarefa do administrador é manter operacional o repositório, de acordo com
| + | |
| − | as determinações da instituição mantenedora. Isso, compreende um conjunto sistemático
| + | |
| − | de procedimentos que mantêm o repositório em pleno funcionamento, conforme orientações
| + | |
| − | estabelecidas pelos seus gestores. Dessa forma, as tarefas dos administradores constituem
| + | |
| − | os principais procedimentos de um repositório.
| + | |
| − | | + | |
| − | Cabe salientar que as tarefas do administrador costumam refletir em todo o repositório. Em muitos casos, algumas dessas tarefas envolvem parâmetros que alteram
| + | |
| − | todo o comportamento do repositório. Essa responsabilidade corresponde ao dever que o
| + | |
| − | administrador tem de manter o repositório alinhado às diretrizes da instituição, que podem
| + | |
| − | mudar dependendo do contexto.
| + | |
| − | | + | |
| − | O DSpace é um software altamente configurável. Assim, cabe ao administrador
| + | |
| − | garantir que as opções de configuração reflitam as políticas definidas para o repositório.
| + | |
| − | Em muitos casos, há diversas opções, cabendo ao administrador implementar ou interagir
| + | |
| − | com a equipe técnica para que determinada opção seja implementada.
| + | |
| − | | + | |
| − | Como os administradores possuem acesso a todas as tarefas do DSapce, em muitos
| + | |
| − | casos, podem executar todos os papéis. Essa facilidade é útil na verificação e solução de
| + | |
| − | problemas, principalmente os relacionados à submissão de itens. Nesse caso, o administrador recebe e-mails automáticos de todos os processos que estão ocorrendo e pode executar
| + | |
| − | tarefas ou apenas acompanhar o desenrolar dos processos.
| + | |
| − | | + | |
| − | Outra facilidade concedida ao administrador é poder simular outro usuário. Sabe-se
| + | |
| − | que o gerenciamento de senhas do DSpace é de responsabilidade de cada usuário, e que
| + | |
| − | nem mesmo o administrador conhece as senhas de outros usuários. O administrado tem
| + | |
| − | a opção de, ao editar um usuário, poder se logar como se fosse o próprio. Essa facilidade
| + | |
| − | é útil na verificação de problemas de permissão.
| + | |
| − | | + | |
| − | A administração pode ser compartilhada ou divida. O compartilhamento ocorre
| + | |
| − | quando há mais de um usuário administrador, o que implica em delegar algumas tarefas
| + | |
| − | do administrador a outros usuários. É recomendável que se tenha mais de um usuário com
| + | |
| − | acesso de administrador, mesmo que esse usuário não exerça esse papel efetivamente.
| + | |
| − | Por outro lado, apenas em repositórios grandes é recomendável ter os administradores de
| + | |
| − | comunidade ou coleção.
| + | |
| − | | + | |
| − | Nem todas as tarefas do administrador podem ser delegadas a outros usuários, apenas o gerenciamento de comunidades e coleções. A maior parte das tarefas não pode ser
| + | |
| − | delegada. Verificar e corrigir problemas, por exemplo, é uma tarefa típica do administrador
| + | |
| − | que não pode ser transferida a outros usuários. Deste modo, as tarefas do administrador
| + | |
| − | requerem uma dose de poder de decisão que somente ele possui, alinhado aos propósitos
| + | |
| − | da instituição em relação ao repositório.
| + | |
| − | | + | |
| − | ==== Políticas ====
| + | |
| − | | + | |
| − | As políticas em um repositório são recomendações que orientam na implantação e
| + | |
| − | gerenciamento do mesmo. Na maioria dos casos, são definidas durante o planejamento do
| + | |
| − | repositório, alinhadas principalmente com a sua finalidade. Essas recomendações não são
| + | |
| − | definitivas, podendo ser alteradas conforme a necessidade ou contexto, dando um maior
| + | |
| − | dinamismo. Assim, as políticas podem ser revistas, o que se reflete no comportamento do
| + | |
| − | repositório.
| + | |
| − | | + | |
| − | Apesar de não ser o objetivo desse manual aprofundar-se em políticas, uma breve
| + | |
| − | discussão se faz necessária para entender como as tarefas do administrador se relacionam
| + | |
| − | com elas. Em alguns casos, as decisões tomadas pelo administrador, na execução de um
| + | |
| − | determinado procedimento, estarão alinhadas com as políticas. Por isso, cabe aqui apresentar
| + | |
| − | algumas das políticas e suas relações diretas com as tarefas dos administradores.
| + | |
| − | | + | |
| − | As políticas agrupam orientações sobre determinados pontos, como por exemplo,
| + | |
| − | conteúdo, acesso ou submissão. Em muitos casos há pontos de intersecção entre as políticas
| + | |
| − | que não apresentam fronteiras claras. Isso não significa necessariamente problemas, mas
| + | |
| − | demonstra como as políticas são integradas. Portanto, pode ser que ao se implementar uma
| + | |
| − | política específica no repositório, seja necessário contemplar também outras políticas.
| + | |
| − | | + | |
| − | A política de conteúdo, por exemplo, abriga vários aspectos, desde os mais gerais,
| + | |
| − | indicando que tipos de documentos ou quais os formatos de arquivos serão aceitos no
| + | |
| − | repositório, até questões mais específicas, sobre que metadados serão implementados.
| + | |
| − | Enquanto os tipos de documentos aceitos não interferem diretamente na configuração do
| + | |
| − | repositório, os formatos e metadados requerem ações do administrador, necessitando de
| + | |
| − | sua intervenção.
| + | |
| − | | + | |
| − | Outra política, como a de acesso, refere-se à permissão de acesso aos itens. Apesar
| + | |
| − | do DSpace ser baseado na filosofia livre, alguns itens depositados no repositório necessitam
| + | |
| − | de restrição de acesso. Assim, pode-se implementar o embargo ou outra forma de restrição
| + | |
| − | e liberação de acesso.
| + | |
| − | | + | |
| − | A política de submissão envolve as etapas necessárias para que um documento esteja
| + | |
| − | disponível para acesso em um repositório. Devido às diversas opções para a submissão,
| + | |
| − | essa política pode ser mais ampla e determinar um fluxo de submissão para todo o repositório,
| + | |
| − | ou especificar fluxos distintos para coleções distintas. Outros pontos dessa política se referem
| + | |
| − | à possibilidade de autoarquivamento, submissão aberta ou restrita, entre outros. Entretanto,
| + | |
| − | todas têm relação com as tarefas do administrador.
| + | |
| − | | + | |
| − | Enfim, percebe-se que as políticas necessitam da intervenção do administrador, direta
| + | |
| − | ou indiretamente, sendo por atuação direta executando procedimentos no repositório, ou
| + | |
| − | orientando a equipe técnica. cabe notar que as políticas determinam todos os aspectos do
| + | |
| − | repositório e o administrador possui um papel importante na implementação e manutenção
| + | |
| − | dessas políticas.
| + | |
| − | | + | |
| − | ==== Menu do administrador ====
| + | |
| − | | + | |
| − | ===== [[Menu do administrador na interface JSPUI]] =====
| + | |
| − | | + | |
| − | ===== [[Menu do administrador na interface XMLUI]] =====
| + | |
| − | | + | |
| − | === Administradores de comunidade ===
| + | |
| − | | + | |
| − | Os administradores do repositório podem dividir a responsabilidade, delegando administradores às comunidades. Esse procedimento permite que usuários tenham a permissão
| + | |
| − | de administradores, porém, somente em uma determinada comunidade. cria também uma
| + | |
| − | hierarquia de administradores na qual, apesar de ter os privilégios de administrador restritos
| + | |
| − | a uma comunidade, cada um está subordinado ao administrador do repositório.
| + | |
| − | | + | |
| − | Pode-se ter não apenas administradores de comunidade, mas também administradores
| + | |
| − | de subcomunidades, independente da posição hierárquica. Esses administradores podem
| + | |
| − | gerenciar os recursos, o que inclui dar ou retirar permissões de acesso aos recursos daquela comunidade ou subcomunidade. Isso facilita o trabalho do administrador geral do repositório.
| + | |
| − | | + | |
| − | Antes de se conceder o privilégio de administrador de comunidade, é importante
| + | |
| − | lembrar que esses usuários terão também direitos sobre as subcomunidades, coleções
| + | |
| − | e itens que estão hierarquicamente subordinados a essa comunidade. Por esse motivo,
| + | |
| − | não é muito recomendável ter muitos administradores de comunidades e de submcomunidades que possam vir a gerar sobreposição de direitos. Assim, se evita problemas de
| + | |
| − | gerenciamento.
| + | |
| − | | + | |
| − | === Administradores de coleção ===
| + | |
| − | | + | |
| − | As coleções podem ter administradores delegados pelos administradores do repositório para gerenciar os seus recursos, que nesse caso tem relação direta com os itens
| + | |
| − | agrupados nas coleções. Por não existir uma subcoleção, a coleção agrupa itens. Portanto,
| + | |
| − | o administrador de coleção gerencia a própria coleção e seus itens.
| + | |
| − | | + | |
| − | Esses administradores podem ser delegados na criação da coleção ou, posteriormente, na alteração da coleção. Assim, pode-se conceder ou retirar esse privilégio
| + | |
| − | quando necessário. O importante é a possibilidade que esses usuários têm de gerenciar
| + | |
| − | os recursos.
| + | |
| − | | + | |
| − | É importante também o gerenciamento harmônico entre os administradores gerais,
| + | |
| − | de comunidade e de coleção, pois os recursos gerenciados por eles estão encadeados de
| + | |
| − | forma hierárquica, ou seja, o administrador geral possui direitos sobre as comunidades, que
| + | |
| − | por sua vez possuem administradores com direitos sobre as coleções. Essa sobreposição
| + | |
| − | de direitos deve ser bem gerenciada para evitar problemas.
| + | |
