Guias de uso

• 1: Pesquisar e mapear dados
• 2: Fluxo de importação de dados
• 3: Organizar e publicar datasets
• 4: Importar filogenias para o backbone
• 5: Curadoria de bibliotecas compartilhadas
• 6: Vouchers, etiquetas e solicitações
• 7: Tutoriais

1 - Pesquisar e mapear dados

Quem pode usar

Visitantes podem consultar o conteúdo público. Usuários autenticados também podem ver registros liberados para seu nível de acesso e aqueles a que têm acesso por projetos, datasets ou biocoleções. Os mesmos filtros podem produzir resultados diferentes para usuários com permissões diferentes.

Escolher a ferramenta

• Use as listas de registros para pesquisar um tipo específico de objeto, conferir detalhes e navegar por suas relações.
• Use o Data Explorer para combinar filtros e descobrir registros de dados relacionados.
• Use o Map Explorer para examinar a distribuição espacial dos resultados e abrir os detalhes de localidades e indivíduos.
• Use a API GET ou o pacote OpenDataBio-R quando precisar de uma consulta reproduzível ou de resultados para análise.

Pesquisar registros

1. Comece com o menor conjunto de filtros que represente sua pergunta.
2. Confira se o filtro taxonômico deve corresponder apenas ao taxon informado ou também aos seus descendentes.
3. Quando usar uma localidade, confirme se a consulta inclui suas localidades descendentes.
4. Use projeto ou dataset quando a pergunta depender da origem ou da política dos dados.
5. Inspecione alguns registros antes de exportar o conjunto completo.

Resultados públicos publicados podem ser encontrados por meio das versões de datasets que os contêm. Um registro editável e uma versão publicada não são a mesma coisa: a versão representa um snapshot fixo.

Usar o mapa

O Map Explorer pode mostrar localidades, indivíduos, parcelas e transectos. Em grandes conjuntos, o mapa utiliza tiles vetoriais e geometrias simplificadas para responder rapidamente. Essa representação é adequada para navegação, mas não substitui a geometria oficial fornecida no registro ou na exportação.

Localidades podem representar ambientes terrestres ou marinhos. Algumas localidades de referência são mantidas pelo sistema; usuários comuns não devem editá-las sem a orientação dos administradores da instalação.

Exportar resultados

Exportações pequenas podem ser retornadas diretamente. Exportações grandes são preparadas em segundo plano como UserJobs. Depois de solicitar uma exportação:

1. abra a lista de UserJobs;
2. acompanhe o progresso e os logs;
3. examine avisos ou erros;
4. baixe o arquivo quando a tarefa terminar;
5. preserve o README e os metadados dos campos junto com os dados.

Uma exportação de consulta representa os resultados daquele momento. Para citar uma publicação fixa, prefira uma versão de dataset.

Perfis e formatos de exportação

As exportações comuns incluem campos locais do OpenDataBio e campos de intercâmbio, como Darwin Core. Consulte a tabela de campos do endpoint GET e preserve o README e os metadados produzidos com o arquivo.

Instalações que trabalham com coleções botânicas também podem oferecer um perfil BRAHMS/INPA. Ele reorganiza dados de Indivíduos ou Vouchers, Localidades, Taxons, coletores, identificações e medições em colunas destinadas a esse fluxo de intercâmbio. Escolha explicitamente se o registro-base é o Indivíduo ou o Voucher e confira os metadados da exportação; o perfil não transforma registros incompletos em dados curatoriais completos.

Continuar no R

O tutorial Obter dados com R demonstra autenticação, taxons, localidades, indivíduos, medições, mídias e vouchers. Use o Data Explorer para construir e conferir uma pergunta; depois traduza os mesmos filtros para R quando precisar reproduzir a análise.

2 - Fluxo de importação de dados

Uma importação confiável não consiste em enviar todas as tabelas de uma vez. O fluxo recomendado é iterativo: preparar uma etapa, verificar o que já existe, enviar um lote pequeno, recuperar os IDs produzidos, reconciliá-los com a tabela de origem e validar o resultado antes de importar os objetos dependentes.

Antes de enviar dados

1. Defina o projeto e o dataset de destino.
2. Confirme que sua conta é colaboradora ou administradora dos objetos que serão alterados.
3. Preserve uma cópia imutável dos dados recebidos.
4. Acrescente à tabela de trabalho uma chave local única, como source_row_id. Ela permitirá associar cada resultado à linha original.
5. Normalize codificação, datas, valores ausentes, números decimais e nomes de colunas.
6. Consulte as bibliotecas compartilhadas antes de criar Pessoas, Referências, Taxons, Localidades ou Traits.
7. Confira os campos do endpoint na API POST.

Não substitua a chave local pelos IDs do OpenDataBio. Mantenha ambos: a chave local documenta a origem; o ID ou UUID permite relacionar registros no sistema.

Ordem de dependências

Uma sequência comum é:

Essa ordem deve ser adaptada ao conjunto. Uma linha pode usar nomes, siglas ou outros identificadores aceitos pelo endpoint, mas guardar os IDs/UUIDs obtidos reduz ambiguidades nas etapas seguintes.

Validar coordenadas antes da importação

O endpoint POST locations-validation recebe latitude e longitude em graus decimais. Ele permite verificar previamente quais Localidades registradas contêm cada ponto, antes de criar Indivíduos ou Localidades automáticas.

Use essa etapa para detectar:

• latitude e longitude trocadas;
• sinal incorreto nos hemisférios sul ou oeste;
• pontos fora do país, estado, município ou área de estudo esperados;
• pontos que caem em unidades de conservação, terras indígenas ou camadas ambientais já cadastradas;
• coordenadas repetidas ou com precisão inadequada.

Exemplo em R:

library(opendatabio)

cfg = odb_config(
  base_url = "http://localhost/opendatabio/api",
  token = Sys.getenv("ODB_TOKEN")
)

coordinates = data.frame(
  source_row_id = c("plot-001", "plot-002"),
  latitude = c(-3.101, -3.115),
  longitude = c(-60.120, -60.135)
)

job = odb_validate_locations(
  coordinates[c("latitude", "longitude")],
  odb_cfg = cfg
)

odb_get_jobs(params = list(id = job$id), odb_cfg = cfg)
validated = odb_get_jobs(
  params = list(id = job$id, get_file = 1),
  odb_cfg = cfg
)

Reassocie o resultado a source_row_id pela ordem ou por uma chave preservada no arquivo de trabalho. Revise casos inesperados manualmente. A validação não decide se uma coordenada é cientificamente correta; ela informa sua relação com as Localidades existentes.

Ciclo de cada UserJob

1. Enviar um lote pequeno

Comece com algumas linhas representativas: uma simples, uma com relações e uma que você espera que produza aviso ou erro. Guarde o ID do UserJob retornado.

2. Acompanhar o processamento

O estado pode ser Submitted, Processing, Success, Failed ou Cancelled. Acompanhe também o percentual e o log. Não envie novamente o mesmo lote apenas porque a tarefa ainda está processando.

3. Examinar resultados por linha

Na interface, abra os resultados do UserJob. O arquivo de resultados pode conter:

• row: número da linha recebida;
• status: resultado daquela linha;
• id: ID criado ou encontrado no OpenDataBio;
• first_field e first_value: valores usados para reconhecer a entrada;
• error: motivo pelo qual a linha não foi concluída;
• warning: situação que exige revisão, mesmo quando existe um ID.

Uma tarefa com estado Success pode conter avisos ou resultados que reutilizam registros existentes. Valide linha por linha.

4. Reconciliar com a tabela enviada

Baixe os resultados e acrescente-os à tabela de trabalho sem alterar a cópia original. Um padrão útil é manter:

Use row para relacionar o arquivo de resultados à ordem enviada e confira first_field/first_value antes de copiar o ID. Se o cliente R fornecer uma tabela de IDs afetados, aplique a mesma conferência. Nunca associe IDs apenas pela posição depois de ordenar ou filtrar uma das tabelas.

5. Validar os registros no servidor

Consulte por ID ou UUID os registros criados ou reutilizados e compare campos essenciais com a entrada. Para dados espaciais, confira o mapa; para Taxons, confira nome aceito, autoria e pai; para medições, confira Trait, objeto, valor, unidade, data e Pessoa.

6. Corrigir somente as linhas necessárias

Separe erros de entrada, duplicatas legítimas e falhas externas. Corrija a tabela de trabalho e envie somente as linhas pendentes. Registre o novo ID de UserJob para manter a rastreabilidade de cada tentativa.

7. Avançar para a próxima dependência

Somente depois de reconciliar e validar uma etapa, use seus IDs na etapa seguinte. Por exemplo:

1. importe Pessoas e registre person_id;
2. use esses IDs em coletores, identificadores e medidores;
3. importe Taxons e Localidades e registre seus IDs;
4. importe Indivíduos usando dataset, coletores, Taxon e Localidade já conferidos;
5. use individual_id para Vouchers, medições, mídias e histórico de identificações.

Exemplo concreto de encadeamento

Considere uma planilha de árvores medidas em parcelas:

1. Pessoas: localize ou importe coletores e medidores; acrescente seus IDs.
2. Referências: importe DOIs ou BibTeX usados nas identificações e Traits.
3. Taxons: valide nomes publicados e resolva morfotipos separadamente.
4. Parcelas: localize as parcelas existentes; crie apenas as ausentes.
5. Coordenadas: execute locations-validation e revise os pontos fora das parcelas ou unidades administrativas esperadas.
6. Traits: localize dbh, altura e demais variáveis por export_name.
7. Indivíduos: importe um lote piloto, recupere individual_id e confira no mapa.
8. Medições: use individual_id, trait_id, Pessoa, data e dataset.
9. Validação final: consulte indivíduos e medições, compare contagens e preserve os arquivos de resultados dos UserJobs.

Encerrar a importação

Uma importação está concluída quando:

• todas as linhas possuem resultado documentado;
• erros foram corrigidos ou justificados;
• avisos foram revisados;
• IDs e UUIDs foram incorporados à tabela de trabalho;
• registros foram consultados novamente no OpenDataBio;
• contagens, relações, datas, coordenadas e permissões foram conferidas;
• os arquivos de entrada, resultados e IDs dos UserJobs foram preservados.

Continue nos tutoriais de importação com R para exemplos de cada objeto.

3 - Organizar e publicar datasets

Quem pode fazer o quê

• Visitantes e visualizadores podem consultar ou baixar o conteúdo permitido pela política, mas não alteram o dataset.
• Colaboradores podem trabalhar com os registros autorizados, mas não devem definir participantes, política ou publicação.
• Administradores do dataset configuram acesso, participantes, metadados e versões.
• Superadministradores podem intervir em qualquer dataset para manter o sistema, mas a curadoria e a decisão de publicar pertencem aos responsáveis científicos pelo dataset.

Dataset e versão de dataset

Um dataset é um conjunto gerenciado que pode continuar mudando. Ele organiza registros e participantes e define como esses dados devem ser acessados.

A visibilidade configurada no dataset e a visibilidade permitida para seus registros determinam quem pode encontrá-los nas listas, exploradores, mapas e exportações. Tornar a página do dataset visível não significa publicar todos os registros nem conceder licença de uso. Da mesma forma, associar um registro a mais de um dataset pode envolver políticas diferentes; confira a política efetiva antes de prometer acesso.

Uma versão de dataset é um snapshot preparado para distribuição. Ela possui UUID, data e arquivos próprios e não deve mudar silenciosamente quando os registros do dataset forem editados depois.

Use a página do dataset para o trabalho contínuo. Use o UUID da versão para links, citações e análises que precisam apontar para conteúdo fixo.

Preparar o dataset

Antes de publicar, o administrador deve:

1. confirmar o título, a descrição e o projeto;
2. revisar administradores, colaboradores e visualizadores;
3. definir visibilidade e política de acesso;
4. conferir licença, política de uso e acordo de download;
5. ordenar autores e criadores e registrar seus papéis;
6. associar referências e marcar citações obrigatórias;
7. revisar os registros e os filtros que definem o escopo;
8. decidir se a lista taxonômica pode ser compartilhada;
9. verificar datasets relacionados e os metadados explicativos.

Uma política não é apenas texto informativo: ela orienta a forma de uso e pode afetar a visibilidade dos registros. Alterações devem ser discutidas com os responsáveis pelo dataset antes da publicação.

Criar e conferir uma versão

1. Abra a ação de criação de versão no dataset.
2. Defina versão, data, escopo e filtros.
3. Confira autores, licença, política, citação e metadados.
4. Gere a versão e acompanhe o UserJob relacionado, quando houver.
5. Abra a página pública pelo UUID.
6. Baixe o arquivo principal e, quando existir, o arquivo de mídias.
7. Confira README, metadados dos campos, contagem de registros e uma amostra dos dados.
8. Teste o acordo de download e a visibilidade com uma conta que não seja administradora.

Os arquivos de versões são persistentes. Administradores da instalação devem incluí-los nos backups junto com o banco de dados; não devem tratar esses arquivos como exportações temporárias.

Depois da publicação

Administradores do dataset podem consultar o registro de uso e exportá-lo para relatórios. Esse registro indica acessos e downloads; não altera permissões nem prova, sozinho, como os dados foram utilizados.

Se os dados precisarem de correção, corrija o dataset gerenciado e publique uma nova versão. Não substitua silenciosamente os arquivos de uma versão já citada.

Relação com a API e o R

A API pode listar datasets, consultar registros associados e preparar exportações. O R é adequado para revisar o escopo e a consistência dos dados antes da publicação. O ato de publicar, entretanto, deve ser realizado por um administrador responsável, depois da revisão de política, autoria e metadados.

4 - Importar filogenias para o backbone

Objetivo do fluxo atual

A importação permite comparar os terminais e relações de uma árvore de origem com os Taxons existentes. Os rótulos da árvore precisam ser associados a conceitos taxonômicos da instalação antes que qualquer mudança no backbone seja considerada.

Importar a árvore não significa incorporá-la automaticamente. Ela funciona como uma proposta que deve ser conferida e aprovada.

Preparar uma importação

Antes de importar:

1. preserve o arquivo original;
2. registre a referência bibliográfica ou o DOI da fonte;
3. confira os rótulos dos terminais e possíveis homônimos;
4. verifique se os Taxons correspondentes já existem;
5. resolva previamente nomes ausentes pelo fluxo normal de cadastro e validação taxonômica;
6. documente o clado objetivo e a interpretação que se pretende incorporar.

Depois da importação, revise terminais não vinculados, correspondências ambíguas, conflitos taxonômicos e relações incompatíveis com o backbone atual. Um rótulo igual ao nome de um Taxon não garante que representam o mesmo conceito taxonômico.

Aprovação administrativa

A incorporação ao backbone afeta uma biblioteca compartilhada por toda a instalação e, por isso, exige revisão e aprovação de um superadministrador. A decisão deve considerar a referência, o escopo da árvore, a correspondência dos Taxons e os conflitos apresentados.

Enquanto o fluxo permanecer experimental, a documentação não garante suporte a publicação, compartilhamento, análise, versionamento ou exportação geral de filogenias. Recursos visíveis na interface podem servir apenas à revisão da importação e podem mudar em versões futuras.

5 - Curadoria de bibliotecas compartilhadas

Taxons, Pessoas, Referências Bibliográficas, Localidades, Traits e nomes populares são bibliotecas compartilhadas. Um registro criado para um projeto pode ser reutilizado por muitos outros; por isso, procure antes de criar e não trate uma correção global como se afetasse apenas o seu dataset.

Validação externa de Taxons

Usuários plenos podem abrir a ferramenta de validação e limitar a análise por projeto, dataset ou raiz taxonômica. A ferramenta pode localizar nomes sem referência de publicação, sem chaves externas ou com divergências de validade, nome aceito e hierarquia.

Fluxo recomendado:

1. escolha um escopo pequeno e uma fonte adequada ao grupo;
2. execute a verificação e aguarde o UserJob;
3. separe resultados seguros, conflitos, Taxons ausentes e decisões manuais;
4. para fungos, revise primeiro o Index Fungorum; para plantas, compare Tropicos e IPNI; use o GBIF como fonte ampla, sem presumir que resolve toda divergência;
5. aceite uma mudança de pai somente quando a hierarquia local realmente deva mudar;
6. aplique diretamente apenas alterações para as quais você possui permissão;
7. quando não puder atualizar o Taxon, envie uma sugestão para revisão;
8. confira os Taxons alterados e o UserJob final.

Conflitos entre fontes são decisões curatoriais. A ferramenta não deve trocar automaticamente um conceito taxonômico apenas porque uma fonte externa apresenta outro nome aceito. Operações administrativas em lote e alterações amplas no backbone devem ser revisadas por superadministradores.

Taxons duplicados

A ferramenta de Taxons duplicados é exclusiva de superadministradores. Ela ignora nomes não publicados na busca automática, escolhe um registro principal, copia metadados e chaves externas ausentes e só remove ramos duplicados quando não existe uso protegido no próprio nó ou em seus descendentes.

Antes de unir, compare autoria, publicação, validade, nome aceito, pai, chaves externas e relações nos descendentes. Homônimos e conceitos taxonômicos diferentes não são duplicatas mesmo quando a grafia coincide. Execute grupos pequenos e confira o backbone e os registros relacionados após cada operação.

Localidades compartilhadas e duplicações

Localidades são compartilhadas por toda a instalação. Países, estados, municípios, unidades de conservação, terras indígenas, camadas ambientais, parcelas e transectos não pertencem exclusivamente ao projeto que os cadastrou. Antes de criar uma nova Localidade, pesquise pelo nome, caminho hierárquico, tipo e geometria.

Países e unidades administrativas

Um país deve existir uma única vez, com o código de país correto e a geometria adotada pela instalação. Estados, províncias, municípios e outros níveis devem ser cadastrados sob o pai correto e de acordo com a convenção de níveis administrativos definida para o país. Não crie outro país ou município apenas porque a grafia ou o idioma do nome é diferente; confirme se o registro existente deve ser corrigido ou traduzido.

Novos países e grandes conjuntos de unidades administrativas devem ser coordenados com os superadministradores. Eles afetam a detecção automática de pais, a validação de coordenadas e muitos registros de usuários.

Unidades de conservação, terras indígenas e camadas ambientais

Essas Localidades podem se sobrepor à hierarquia administrativa e funcionar como relações espaciais adicionais. Antes de importar:

1. procure o nome oficial, siglas e versões anteriores do limite;
2. registre a fonte, a data e a versão da geometria nas notas ou metadados;
3. confirme o tipo correto de Localidade;
4. use geometria WGS84 e valide polígonos e multipolígonos;
5. verifique sobreposição e duplicação com camadas já cadastradas;
6. combine com a administração como uma atualização de limites oficiais será tratada sem alterar silenciosamente análises anteriores.

Parcelas, subparcelas e transectos

Parcelas e transectos também são objetos compartilhados. Pesquise pelo nome, localidade pai, projeto, coordenadas e dimensões. Nomes genéricos como “Parcela 1” não são suficientes para distinguir unidades de amostragem de projetos diferentes.

Antes de criar, defina uma convenção de nomes e confira:

• localidade pai e caminho completo;
• ponto inicial ou geometria;
• orientação e dimensões cartesianas;
• relação entre parcela e subparcela;
• comprimento e largura de busca do transecto;
• datum e unidade das coordenadas.

Não crie uma segunda parcela para corrigir dimensões ou geometria. Se a Localidade já possui dados relacionados, somente um superadministrador pode alterá-la, e a correção deve considerar o efeito sobre as posições globais dos indivíduos.

Pontos e localidades automáticas

Alguns fluxos de importação criam Localidades de ponto automaticamente a partir das coordenadas dos indivíduos. Antes de cadastrar pontos manualmente em lote, confirme se esse mecanismo já atende ao caso. O formulário verifica geometrias e pontos semelhantes, mas o usuário ainda deve examinar as correspondências antes de confirmar um novo registro.

Quem pode corrigir

Usuários plenos podem criar Localidades e editar apenas aquelas que ainda não possuem indivíduos, vouchers, medições ou mídias relacionados. Depois que uma Localidade passa a ser usada, apenas superadministradores podem alterá-la. A exclusão também exige que não existam dados relacionados nem descendentes.

Ao encontrar uma duplicata já utilizada, não tente contornar a restrição criando outra versão. Documente os registros envolvidos e solicite que um superadministrador avalie hierarquia, geometrias e relações antes de corrigir.

Pessoas duplicadas

Antes de criar uma Pessoa, pesquise variações de nome, abreviatura, instituição, e-mail e ORCID. Não crie uma segunda Pessoa apenas para corrigir grafia ou acrescentar metadados.

A ferramenta de substituição de duplicatas é exclusiva de superadministradores. Ela redireciona relações como coleta, autoria de versões, identificação, medição, especialidade taxonômica e autoria de nomes não publicados para uma Pessoa escolhida como registro principal. Depois tenta remover os registros substituídos.

Antes de unir Pessoas, o administrador deve:

1. confirmar que representam a mesma pessoa real;
2. escolher como principal o registro com nome, abreviatura, ORCID e instituição mais completos;
3. verificar se algum registro está associado ao perfil de um usuário;
4. conferir possíveis papéis distintos nas mesmas identificações ou medições;
5. executar a união e revisar o histórico e as relações do registro resultante.

Não use essa ferramenta para homônimos. Se dois usuários já possuem Pessoas padrão diferentes, a associação não pode ser simplesmente transferida para um registro que já pertence a outra conta.

Referências duplicadas

Pesquise DOI e chave BibTeX antes de cadastrar. Quando o sistema indicar DOI ou chave existente, compare os registros; não modifique arbitrariamente a chave apenas para criar uma segunda referência. Corrija o registro existente se você tiver permissão e ele representar a mesma publicação.

Nomes populares

Um nome popular deve registrar o idioma e pode ser relacionado a Taxons, Indivíduos ou Localidades. Use citações para documentar fonte, contexto e variação regional. A mesma grafia em idiomas ou regiões diferentes não implica necessariamente o mesmo uso.

Usuários plenos podem criar nomes populares. Um usuário comum só pode editar um registro criado por ele; superadministradores podem editar qualquer registro. Uma exclusão é bloqueada quando existem citações pertencentes a outros usuários.

Antes de criar:

1. pesquise o nome e o idioma;
2. confira os objetos já relacionados;
3. determine se deve acrescentar uma relação ou citação ao registro existente;
4. crie outro registro apenas quando o idioma ou o conceito registrado for realmente diferente.

6 - Vouchers, etiquetas e solicitações

Este guia reúne operações posteriores ao cadastro de Indivíduos: identificação em lote, criação de Vouchers, impressão de etiquetas e solicitações tratadas por biocoleções administradas no OpenDataBio.

Identificar indivíduos em lote

Use a identificação em lote quando vários Indivíduos compartilham a mesma determinação taxonômica. Antes de aplicar:

1. filtre e confira os Indivíduos selecionados;
2. confirme o Taxon, os identificadores e a data;
3. registre modificador, referência e notas quando necessários;
4. verifique se a nova identificação substitui ou complementa informação anterior;
5. acompanhe o UserJob e revise o Histórico de Identificações.

Não selecione indivíduos apenas por semelhança de nome ou por uma consulta ampla sem conferir a lista. O Histórico de Identificações preserva determinações anteriores; o log de atividades registra alterações no sistema, mas não o substitui.

Criar e revisar Vouchers

Um Voucher representa uma amostra física de um Indivíduo depositada em uma BioColeção. Confira:

• Indivíduo de origem;
• BioColeção e número de catálogo;
• coletores e data;
• tipo nomenclatural, quando aplicável;
• referências e mídias diretamente relacionadas ao Voucher.

O Voucher herda a identificação e a Localidade do Indivíduo. Registre uma medição ou mídia diretamente no Voucher somente quando ela descreve a amostra, e não o organismo de forma geral.

Gerar etiquetas

O gerador produz etiquetas para os modelos suportados e permite selecionar formato de folha, dimensões, margens, conteúdo, bordas e outras opções de impressão. Existem formatos predefinidos, incluindo modelos Pimaco, e geração de PDF para impressão.

Fluxo recomendado:

1. filtre e selecione poucos registros;
2. escolha o tipo de etiqueta adequado ao objeto;
3. selecione a folha e confira dimensões e margens;
4. gere uma prévia e imprima uma folha de teste em escala de 100%;
5. compare códigos, nomes, números de coleção e identificadores com os registros;
6. somente depois gere o lote completo.

As opções mais recentes são lembradas nas configurações do usuário. Um usuário pode salvar a configuração como preset, reutilizá-la, duplicar um preset compartilhado e, se for o proprietário, atualizá-lo ou excluí-lo. Presets públicos podem ser usados por outras pessoas, mas somente o proprietário pode alterá-los. Um preset guarda configuração de impressão; não congela os dados dos registros selecionados.

Solicitações de biocoleções

O fluxo de solicitações fica disponível quando existe pelo menos uma BioColeção administrada pelo sistema. Ele atende a dois casos diferentes: o depósito de material já representado por Indivíduos no banco e a solicitação de material que já está depositado em uma coleção. Não confunda esse fluxo com uma solicitação de acesso a um dataset.

Depositar material e registrar Vouchers

Use este fluxo quando você cadastrou seus dados de coleta como Indivíduos e quer depositar as amostras em uma BioColeção gerenciada pelo OpenDataBio.

1. confira a Localidade, os coletores, a data e a identificação de cada Indivíduo;
2. selecione os Indivíduos e indique a BioColeção de destino;
3. envie a solicitação de registro de Vouchers e acompanhe o UserJob que cria a solicitação;
4. um administrador ou colaborador da coleção revisa os itens e pode registrar correções ou atualizar a identificação solicitada;
5. se o depósito for aceito, a coleção informa o dataset dos novos Vouchers e o primeiro número de catálogo; o sistema cria um Voucher para cada Indivíduo e numera a sequência;
6. confira no resultado quais itens foram registrados ou recusados.

Somente administradores e colaboradores do dataset do Indivíduo podem incluí-lo na solicitação. A interface também exige que esses Indivíduos estejam em um dataset acessível ao público ou a usuários registrados, para que a coleção possa avaliá-los.

O registro do Voucher muda a responsabilidade de edição. Se a BioColeção possui equipe cadastrada no OpenDataBio:

• somente membros dessa coleção podem editar o Voucher;
• somente usuários que sejam membros de todas as coleções gerenciadas às quais o Indivíduo está vinculado podem editar o Indivíduo, inclusive sua identificação e Localidade;
• o superadministrador da instalação mantém acesso administrativo;
• Medições e Mídias vinculadas ao Indivíduo não passam para o controle da coleção: continuam obedecendo aos seus próprios datasets e permissões.

Assim, o depositante conserva a autoria e o acesso definidos pelos datasets, mas não deve esperar continuar editando o registro curado pela coleção, a menos que também faça parte da equipe dela.

Solicitar empréstimo de material depositado

Use este fluxo quando os Vouchers já existem em uma BioColeção gerenciada e você quer solicitar o material físico.

1. localize e selecione os Vouchers desejados;
2. abra a solicitação, informe instituição, contato e mensagem com a finalidade e as condições pretendidas;
3. acompanhe separadamente o estado de cada Voucher;
4. a equipe da coleção confere os itens e registra o empréstimo ou a recusa;
5. quando o material retorna, a coleção registra a devolução. O sistema também admite o encerramento como doação quando esse for o destino acordado.

Os estados implementados para esse fluxo distinguem item solicitado, conferido, emprestado, recusado, devolvido e doado. Eles documentam a tramitação no OpenDataBio; embalagem, transporte, prazos e termos institucionais continuam sendo responsabilidade da coleção.

Responsabilidades e solicitações com várias coleções

O solicitante cria e acompanha a solicitação. Administradores e colaboradores da BioColeção podem anotar e tratar seus itens; para uma solicitação que reúne mais de uma coleção, o usuário precisa integrar todas elas. Alterar os dados administrativos da solicitação exige ser administrador de todas as coleções envolvidas, salvo para um superadministrador da instalação.

O histórico e o estado pertencem a cada item. Por isso, uma mesma solicitação pode terminar com parte dos Vouchers registrados ou emprestados e parte recusada. Use notas para justificar decisões e não exclua uma solicitação em andamento para corrigir uma anotação.

7 - Tutoriais

Os tutoriais aplicam os conceitos e guias de uso em fluxos reproduzíveis com o pacote OpenDataBio-R.

• Obter e conferir dados com R
• Preparar e importar dados com R
• Visão geral, sequência recomendada e melhorias planejadas

Antes de importar, consulte também o Fluxo de importação de dados, que explica dependências, validação e reconciliação dos resultados de UserJobs.