Objetos de Acesso

Os objetos centrais são: Localidades, Vouchers, Individual, Taxons e Arquivos de Mídia. Essas entidades são consideradas “centrais” porque podem receber Medições, ou seja, você pode registrar valores para qualquer Variável.

Conjuntos de dados controlam acesso aos dados e representam um publicação de dados dinâmica, cuja versão é definida pela data da última edição do registros incluídos. Conjuntos de dados contém Medições, Indivíduos, Vouchers e Arquivos de Mídia.

Projetos são apenas grupos de Conjuntos de dados e de Usuários, representando grupos de usuários com acessibilidade comum a conjuntos de dados cuja privacidade é definida para ser controlada por um projeto.

BioColeções - este modelo serve para criar uma lista reutilizável de acrônimos de Coleções Biológicas no registro de Vouchers. Mas tem opcionalmente a possibilidade de gerir uma coleção de registros de Vouchers e seus Indivíduos, paralelamente ao controle provido por Conjuntos de dados. O controle é apenas na edição e na entrada de dados. Neste caso a BioColeção é administrada pelo sistema.

Projetos e BioColeções devem ter pelo menos um Usuário definido como administrador, que tem controle total sobre o conjunto de dados ou projeto, incluindo a atribuição das seguintes funções a outros usuários: administrador, colaborador ouvisualizador:

• Colaboradores podem inserir e editar objetos, mas não podem excluir registros, nem alterar o conjunto de dados ou a configuração do projeto.
• Visualizadores têm acesso somente de leitura aos dados que não são de acesso aberto.
• Apenas usuários plenos e super-admins podem ser designados como administradores ou colaboradores. Assim, se um usuário que era administrador ou colaborador de um conjunto de dados for rebaixado a “Usuário registrado”, ele se tornará um visualizador.
• Super-admins apenas podem habilitar uma BioColeção para ser administrada pelo sistema.

BioColeções

O modelo Biocollection tem duas funções: (1) prover uma lista de acrônimos para registrar Vouchers de qualquer Coleção Biológica ; (2) gerir os dados de uma Coleção Biológica, facilitando o registro de novos dados (qualquer usuário entra seus dados usando as validações realizadas pelo software e solicita pela interface aos curadores da Coleção o registro dos dados que é feito pelos usuários autorizados na BioColeção, que a partir da transferência passa a controlar a edição dos dados dos Indivíduos. A opção (2) precisa ser implementada por um usuário SuperAdministrador do sistema, que ao habilitar a BioColeção para ser administrada pelo sistema, implementa o modelo de solicitações ODBRequest para que usuários possam pedir dados, amostras, ou registros e mudanças nos dados.

O objeto Biocollection pode ser uma Coleção Biológica formal, como as registradas no Index Herbariorum, ou qualquer outra Coleção Biológica.

O objeto Biocollection também interage com o modelo Person. Quando uma Pessoa está vinculada a uma Biocoleção, ela será listada como especialista taxonômico e pode ter também um vínculo com Taxons.

Acesso a dados - Usuários plenos podem registrar BioColeções, mas apenas usuários super-administradores podem tornar uma BioColeção adminstrável pelo sistema. Remover BioColeções pode ser feito se não há Vouchers ligados e se não é administrada pelo sistema. Se administrável, o modelo interage com Usuários, que podem ser administradores (curadores, pode tudo) ou colaboradores (podem entrar e editar dados, mas não podem apagar registros). Dados de outros Conjuntos de Dados podem fazer parte da BioColeção, permitindo que usuários tenham seus dados completo, mas o controle da edição dos registros é da BioColeção.

Conjuntos de Dados

Conjuntos de Dados são grupos de Medições, Indivíduos, Vouchers Arquivos de Mídia, e podem ter um ou mais Usuários administrators, collaborators ou viewers.

Administradores podem definir o nível de acesso para:

• acesso público
• restrito à usuários cadastrados
• restrito à usuários autorizados
• restrito à usuários do projeto.

Conjuntos de dados podem ter muitas Referências bibliográficas, que junto com os campos policy, metadata permitem anotar o conjunto de dados com informações relevantes para o compartilhamento de dados: * Vincule qualquer publicação que tenha usado o conjunto de dados e, opcionalmente, indique se são de citação obrigatória ao usar os dados; * Defina uma política de dados específica ao usar os dados além de uma licença pública [CreativeCommons.org]((https://creativecommons.org/licenses/) * Detalhe quaisquer metadados relevantes, além daqueles que são automaticamente recuperados do banco de dados, como as definições das Variáveis medidas.

Versionamento de Conjuntos de Dados

Você pode gerar uma ou mais versões estáticas (dataset_versions) para cada conjunto de dados. Quando fizer isso serão gerados arquivos em csv com todos os dados e metadados para distribuição e acesso rápido. O versionamento inclui:

• version - versionamento semântico para o conjunto de dados
• date - a data da versão
• license/license_version - a licença pública [CreativeCommons.org]((https://creativecommons.org/licenses/)
• policy (opcional) - um markdown para você definir a política de uso dos dados
• citation - você define o que seja incluir na citação para a versão e o Opendatabio gera a citação e fornece um bibtex para ela
• metadata (opcional) - um espaço para você falar dos metadados primários
• filters (opcional) - filtros permitem gerar versões para uma parte dos dados num conjunto de dados (por táxons, localidades, pessoas, traits, datas), registrando exatamente o escopo dos arquivos gerados.
• As versões mantêm a lista de autores (pivô dataset_version_person) do conjunto de dados
• Um identificador único UUID é gerado para cada versão
• Os arquivos gerados são armazenados e referenciados em metadata['files'] e metadata['archives'] com o UUID.
• O nível de acesso da versão (dataset_access) pode ser igual ou menos restritivo que o do conjunto de dados, mas o principal objetivo é que versões tenha acesso público.
• Downloads são auditados, mantendo um log do uso e do acesso;
• A API datasets expõe as versões para listagem e download; a interface web usa um componente Livewire para criar/editar versões com pré-visualização da política e citação.

Projetos

Projetos são apenas grupos de Conjuntos de dados e interagem com Usuários, tendo administradores,colaboradores ou visualizadores. Esses usuários podem controlar todos os conjuntos de dados dentro do Projeto que tenham como política de acesso restrita aos usuários do projeto.

Usuários

O tabela users armazena informações sobre os usuários e administradores do banco de dados. Cada Usuário pode ser associado a uma Pessoa. Quando esse usuário insere novos dados, essa pessoa é usada como a pessoa padrão nos formulários. A pessoa só pode estar associada a um único usuário.

Existem três níveis de acesso possíveis para um usuário: * Usuário registrado (o nível mais baixo) - tem muito poucas permissões * Usuário pleno ou completo - podem ser atribuídos como administradores ou colaboradores de Projetos e Conjuntos de Dados; * SuperAdmin (o nível mais alto). - os superadministradores têm acesso a todos os objetos, independentemente da configuração do conjunto de dados. Categoria para os administradores da instalação.

Cada usuário é atribuído ao nível usuário registrado ao se auto-cadastrar numa instalação do OpenDataBio. Depois disso, alguém que seja SuperAdmin pode promovê-lo a Usuário Pleno ou SuperAdmin. SuperAdmins também podem definir se um usuário pleno tem permissão para promover usuários registrados para usuário pleno. Apenas superAdmins podem remover usuários do banco de dados.

Se o adminstrador do sistema configurar a opção EMAIL_VERIFICATION_ENABLED = true nas configurações do Opendatabio, usuários registrados receberão um link via email para validar o email registrado.

Acesso a dados: os usuários são criados no momento do registro e o acesso aos dados são restritos ao próprio usuário e aos administradores. Usuários registrados autorizados tem acesso apenas ao nome.