This is the multi-page printable view of this section. Click here to print.
Estes guias explicam tarefas completas do ponto de vista de quem usa o OpenDataBio. Para definições de cada tipo de registro, consulte Conceitos. Para parâmetros de integração, consulte a API.
Se você pretende coletar ou importar variáveis definidas pelo usuário, comece por Traits e medições antes dos tutoriais R. Responsáveis pela biblioteca pública também devem ler Governança e curadoria de Traits.
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.
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.
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.
Exportações pequenas podem ser retornadas diretamente. Exportações grandes são preparadas em segundo plano como UserJobs. Depois de solicitar uma exportação:
Uma exportação de consulta representa os resultados daquele momento. Para citar uma publicação fixa, prefira uma versão de dataset.
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.
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.
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.
source_row_id.
Ela permitirá associar cada resultado à linha original.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.
Uma sequência comum é:
| Etapa | Preparar ou localizar | Será usado depois por |
|---|---|---|
| 1 | Pessoas e Referências Bibliográficas | coleta, identificação, medição, Taxons, datasets |
| 2 | Taxons | identificações, medições e nomes populares |
| 3 | Localidades | indivíduos, medições e validação espacial |
| 4 | Traits, unidades e categorias | medições e formulários |
| 5 | Projeto e dataset | indivíduos, vouchers, medições e mídias |
| 6 | Indivíduos e suas ocorrências | vouchers, identificações, medições e mídias |
| 7 | Vouchers e histórico de identificações | medições, mídias e documentação científica |
| 8 | Medições, mídias e nomes populares | conjunto final de dados |
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.
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:
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.
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.
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.
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.
Baixe os resultados e acrescente-os à tabela de trabalho sem alterar a cópia original. Um padrão útil é manter:
| source_row_id | odb_status | odb_id | odb_uuid | odb_error | odb_warning |
|---|---|---|---|---|---|
| person-001 | imported | 812 | … | ||
| person-002 | already registered | 107 | … | registro existente reutilizado | |
| person-003 | error | abreviação duplicada |
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.
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.
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.
Somente depois de reconciliar e validar uma etapa, use seus IDs na etapa seguinte. Por exemplo:
person_id;individual_id para Vouchers, medições, mídias e histórico de
identificações.Considere uma planilha de árvores medidas em parcelas:
locations-validation e revise os pontos fora das
parcelas ou unidades administrativas esperadas.dbh, altura e demais variáveis por export_name.individual_id e confira no
mapa.individual_id, trait_id, Pessoa, data e dataset.Uma importação está concluída quando:
Continue nos tutoriais de importação com R para exemplos de cada objeto. Para uma planilha desconhecida, use o prompt de planejamento com IA e revise o fluxo proposto.
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.
Antes de publicar, o administrador deve:
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.
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.
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.
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.
Uma IA pode examinar uma planilha desconhecida e propor código R para transformá-la, validá-la e importá-la. Trate a resposta como um plano, não como dados validados. Nunca forneça token, senha, coordenadas sensíveis, dados pessoais ou inéditos a um serviço não autorizado. Preserve uma cópia imutável da fonte e revise todo o código gerado.
Anexe o CSV ou XLSX e substitua o texto entre colchetes. Se a IA não ler anexos, forneça nomes das abas e colunas e uma pequena amostra sem dados sensíveis.
Ajude-me a preparar uma importação reproduzível e auditável no OpenDataBio
usando R e o pacote R opendatabio.
Considere que sou iniciante em R e em organização de dados. Estou usando um
chatbot online comum, possivelmente gratuito, que não executa R, não mantém
arquivos entre conversas e pode ter limite de mensagens. Não pressuponha que eu
saiba usar terminal, projetos do RStudio, diretório de trabalho, pacotes ou
objetos do OpenDataBio. Use linguagem simples e explique termos técnicos na
primeira vez em que aparecerem.
Arquivo: anexo. URL base da API: [URL]. Projeto: [nome ou ID]. Dataset: [nome
ou ID]. Os dados descrevem [descrição]. Cada linha representa [significado].
[Informe unidades, códigos, convenções de ausentes e escopo geográfico ou
taxonômico conhecidos.]
Use estas fontes oficiais como contexto técnico obrigatório:
- Documentação do OpenDataBio: https://opendatabio.gitlab.io/docs/
- Visão geral da API: https://opendatabio.gitlab.io/docs/api/
- Campos e regras dos endpoints POST: https://opendatabio.gitlab.io/docs/api/post-data/
- Fluxo de importação: https://opendatabio.gitlab.io/docs/guides/data-import-workflow/
- Tutoriais de importação com R: https://opendatabio.gitlab.io/docs/tutorials/02-post-data-r-vignette/
- Código-fonte e README do OpenDataBio-R: https://gitlab.com/opendatabio/opendatabio-r
Abra e consulte essas URLs antes de propor código. Prefira essas fontes ao seu
conhecimento geral ou a exemplos de terceiros. Para cada função odb_* e campo
da API propostos, indique a página oficial que os documenta. Se não conseguir
acessar uma URL, informe e peça que eu forneça seu conteúdo; não adivinhe.
Registre qualquer aparente incompatibilidade de versões entre a documentação do
servidor e o pacote R.
Ainda não importe nada. Nunca solicite nem imprima meu token; use
Sys.getenv("ODB_TOKEN"). Não invente IDs, correspondências, unidades, datas,
coordenadas ou ausentes. Marque incertezas para minha revisão.
Primeiro examine todas as abas e informe dimensões, possível cabeçalho, colunas
vazias ou duplicadas, tipos inferidos, códigos de ausentes e uma amostra sem
dados sensíveis. Explique o que cada linha representa e sinalize colunas com
múltiplas entidades.
Proponha uma tabela com coluna de origem, objeto e campo OpenDataBio,
transformação, obrigatoriedade, confiança e perguntas. Confira os campos na API
POST e na documentação do cliente R; não invente campos. Crie source_row_id
estável, preserve valores originais ao lado dos normalizados e documente cada
transformação.
Separe tabelas por dependência. Pesquise Pessoas, Referências, Taxons,
Localidades e Traits existentes antes de criar registros; depois trate relações
de Projeto/Dataset, Indivíduos/ocorrências, Vouchers/identificações e, por fim,
Medições/Mídias/nomes populares. Gere tabelas de correspondências, ausências e
ambiguidades. Nunca resolva ambiguidade automaticamente nem use posição como
chave.
Quando houver coordenadas, use locations-validation e sinalize intervalos
inválidos, eixos trocados, geografia inesperada, duplicatas e precisão
inadequada, sem correções silenciosas.
Antes de qualquer POST, valide localmente e grave mapping_review.csv,
validation_errors.csv, ambiguous_matches.csv e import_plan.csv. Proteja toda
gravação com RUN_IMPORT <- FALSE; com FALSE nenhum POST ou PUT pode executar.
Após minha aprovação, importe um lote piloto representativo, guarde cada ID de
UserJob, acompanhe a tarefa, baixe resultados por linha e associe-os por
source_row_id, mantendo odb_status, odb_id, odb_uuid, odb_error e odb_warning.
Interrompa dependências se pré-requisitos falharem; reenvie somente linhas
pendentes corrigidas; nunca apague ou sobrescreva registros. Consulte por GET os
registros criados ou reutilizados, verifique campos e contagens e grave relatório
de reconciliação e sessionInfo().
Organize 00_config.R, 01_inspect.R, 02_transform.R, 03_match_validate.R,
04_pilot_import.R, 05_full_import.R e 06_verify.R, com dependências e instruções.
Além dos scripts, produza um guia operacional passo a passo para iniciantes.
Comece por instalação do R e RStudio, instalação/atualização dos pacotes,
criação de uma pasta exclusiva para a importação, colocação da planilha nessa
pasta e configuração segura de ODB_TOKEN. Forneça somente comandos completos
que eu possa copiar e colar. Diga exatamente em qual programa, arquivo ou
console devo colar cada comando e nunca use apenas expressões vagas como
"configure o ambiente" ou "execute o script".
Apresente uma etapa por vez, nesta ordem: objetivo; arquivos que serão lidos ou
criados; bloco exato para copiar; como executar; resultado esperado; como saber
se funcionou; erros comuns e como corrigi-los; e um ponto de parada. Ao final de
cada etapa, peça que eu cole apenas a mensagem de erro ou o resumo produzido e
espere minha confirmação antes da próxima. Não peça que eu cole token, dados
sensíveis ou a tabela inteira. Se a conversa perder contexto, forneça um pequeno
resumo que eu possa copiar para iniciar uma nova conversa.
Nunca mande executar todos os scripts de uma vez. As etapas 01 a 03 e o teste
com RUN_IMPORT <- FALSE devem ser concluídos antes do lote piloto. Antes do
primeiro POST, mostre uma caixa de verificação em linguagem simples e peça uma
confirmação explícita. Antes da importação completa, exija nova confirmação
após a revisão do piloto. Explique como interromper com segurança, continuar
depois e localizar os arquivos de revisão e resultados.
Antes dos scripts, mostre: (a) interpretação da planilha, (b) ordem e mapeamento,
(c) suposições e ambiguidades e (d) perguntas que devo responder. Aguarde minhas
respostas antes de finalizar mapeamentos de baixa confiança.
Execute primeiro com RUN_IMPORT <- FALSE e depois com um lote piloto. Confirme
que as funções existem na versão instalada do OpenDataBio-R e correspondem à
API POST do servidor. Um UserJob bem-sucedido ainda pode
conter avisos ou registros reutilizados; reconcilie cada linha. Veja também o
fluxo de importação.
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.
Antes de importar:
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.
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.
Traits são definições compartilhadas de variáveis; Medições são os valores dessas variáveis registrados para Localidades, Taxons, Indivíduos, Vouchers ou Mídias. Definir bem o Trait antes da coleta é essencial, porque mudar seu significado depois que outras pessoas o utilizaram pode invalidar dados. Para autoria, permissões de curadoria, consolidação de duplicações, status e ferramentas de tradução, consulte Governança e curadoria de Traits.
export_name, unidade e definição para evitar duplicações;Não reutilize um Trait apenas porque nome e unidade são parecidos. Altura medida
diretamente e altura estimada com clinômetro, por exemplo, podem exigir Traits
distintos. O export_name deve ser único, estável, curto e sem espaços ou
acentos; ele será usado em formulários, importações e exportações.
Categorias devem possuir significado estável, descrições quando o nome não for suficiente e traduções coerentes. Em Traits ordinais, a ordem faz parte da definição. Não use números categóricos quando o valor é realmente uma medição quantitativa.
Cada Medição precisa indicar o Trait, o objeto medido, a Pessoa responsável, a data e o dataset que controla acesso e edição. Acrescente referência quando o valor foi extraído de uma publicação.
Antes de importar em lote:
Consulte os exemplos de importação de Traits com R e importação de Medições com R.
Formulários web agrupam Traits ordenados e podem marcar campos obrigatórios. Uma Tarefa de Formulário aplica o protocolo a objetos-alvo e permite acompanhar o que ainda precisa ser medido. Formulários móveis alimentam o OpenDataBio Collect com protocolo, Taxons, objetos, geolocalização, fotografias e campos para coleta offline.
Defina primeiro dataset, Traits, unidades e categorias; atribua usuários; teste com poucos objetos; sincronize; e confira Medições, coordenadas, Mídias e logs antes de distribuir o formulário. O formulário organiza a entrada, mas não substitui a definição do Trait nem cria outro tipo de dado.
O criador pode editar um Trait válido enquanto ele não estiver em uso ou for usado somente em datasets nos quais o criador é administrador. Curadores de Traits podem manter globalmente a biblioteca pública. Categorias já usadas em Medições exigem um curador para sua redefinição ou reordenação. Quando a correção afetar vários usuários, use o fluxo de governança em vez de alterar silenciosamente um conceito compartilhado.
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.
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:
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.
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 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.
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.
Essas Localidades podem se sobrepor à hierarquia administrativa e funcionar como relações espaciais adicionais. Antes de importar:
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:
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.
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.
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.
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:
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.
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.
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:
Traits formam uma biblioteca pública de toda a instalação. As permissões de um dataset controlam as Medições que usam um Trait; elas não transformam a definição do Trait em um recurso privado do dataset. A governança de Traits protege tanto o significado científico quanto todos os datasets que reutilizam a definição.
Em uma instalação nova, escolha os locales de interface e de conteúdo durante
a configuração; a tradução assistida permanece desabilitada até que o
administrador configure explicitamente um provedor. Depois de atualizar, rode
as migrations, php artisan locales:audit, limpe o cache de configuração e
reinicie os workers da fila. A migration marca os Traits existentes como
válidos, registra o primeiro superadministrador como criador quando houver e
cria as tabelas de governança e revisão de duplicações; não há backfill separado
para Traits.
Depois da instalação, o superadministrador pode atribuir Curador de Traits no perfil de um usuário pleno. Os curadores passam então a revisar a biblioteca compartilhada. Configure os serviços opcionais de tradução, Tropicos e e-mail conforme a Configuração administrativa.
Cada Trait possui um criador e um status:
valid): definição ativa, disponível para novas Medições;duplicate): alias consolidado em outro Trait, indicado por
canonical_trait_id;deprecated): preservado para proveniência, mas não
recomendado para novos usos.Excluir um Trait sem uso pertencente ao próprio usuário remove o registro definitivamente quando não há usos nem dependências protegidas. Isso também vale para a exclusão normal em lote. As demais exclusões permitidas arquivam o Trait com soft delete, mantendo relações e histórico para possível restauração.
Ao consolidar Traits duplicados, Medições, formulários, referências, tags, tipos de objeto e categorias compatíveis são reconciliados com o Trait mantido. O Trait antigo permanece como alias duplicado. Uma importação de Medições que use esse alias é redirecionada ao Trait canônico.
| Perfil | Permissões sobre Traits |
|---|---|
| Usuário registrado | Consulta Traits permitidos pela instalação; não pode criar nem fazer curadoria. |
| Usuário pleno | Cria Traits; examina um Trait individual para possíveis duplicações; sugere pares duplicados aos curadores. |
| Criador do Trait | Edita diretamente seu Trait válido enquanto ele não estiver em uso, ou enquanto todas as Medições que o utilizam pertencerem a datasets nos quais o criador é administrador. Exclui definitivamente seu próprio Trait quando não houver Medições, formulários, Traits dependentes, aliases ou outras referências protegidas. |
| Curador de Traits | Faz a curadoria da biblioteca pública de toda a instalação: edita Traits globalmente, revisa sugestões, varre toda a biblioteca, registra decisões de não duplicação, consolida duplicações, arquiva Traits permitidos, restaura Traits arquivados e exclui explicitamente Traits isolados. |
| Superadministrador | Possui os poderes de curadoria e atribui ou remove a habilidade Curador de Traits no perfil de usuários plenos. |
No model-index de Traits, a exclusão normal remove automaticamente de forma definitiva um Trait isolado pertencente ao usuário que executa a ação. Para registros de outros criadores, curadores e administradores precisam marcar explicitamente Excluir definitivamente os Traits permitidos; sem essa opção, a exclusão permanece recuperável. Cada registro selecionado é verificado individualmente, e Traits protegidos são recusados.
O model-index de Traits separa Traits ativos, Traits duplicados mesclados, Traits descontinuados e Traits arquivados por soft delete. Aliases mesclados recebem uma marca visível e apontam para o Trait canônico. A quantidade de Medições exibida na lista de Traits conta todas as Medições ligadas, pois a biblioteca de Traits é pública; ao abrir esse total, as regras de acesso dos datasets continuam válidas, portanto o usuário pode visualizar menos registros que o total público.
Usuários plenos podem selecionar Traits arquivados no model-index e abrir a
definição arquivada. Esse acesso somente para leitura explica uma colisão de
importação com um export_name reservado; o resultado da importação também
informa o id do Trait arquivado. Isso não concede permissão de restauração ou
curadoria. Na visão arquivada, curadores e administradores podem restaurar os
registros selecionados ou excluir definitivamente os elegíveis. O criador pode
excluir seu próprio Trait legado, arquivado e isolado na página de detalhes.
Usuários registrados continuam vendo somente Traits ativos.
Administrar um projeto ou dataset não torna automaticamente o usuário um curador de Traits. A administração dos datasets, entretanto, participa da regra do criador: ele pode corrigir diretamente um Trait em uso somente quando administra todos os datasets que contêm suas Medições. Quando outros datasets dependem da definição, a correção deve ser conduzida por um curador de Traits.
Alterar ou acrescentar categorias pode mudar o significado de Medições categóricas existentes. Categorias já utilizadas em Medições somente podem ser redefinidas ou reordenadas por um curador de Traits.
Usuários plenos podem abrir Medições → Revisar possíveis traits duplicados, buscar um Trait por export name, nome ou descrição e compará-lo com os registros sugeridos. A comparação usa nomes e descrições multilíngues e exige que os Traits tenham o mesmo tipo. Traits numéricos podem ser apresentados mesmo com unidades diferentes: unidades podem ser convertidas e, portanto, não devem suprimir um alerta de possível duplicação científica.
O usuário pleno não pode consolidar registros. Ele envia uma sugestão e depois visualiza se ela está pendente, confirmada ou rejeitada. Curadores revisam essas sugestões na mesma ferramenta.
Curadores de Traits também podem escolher Varrer toda a base de traits. A varredura roda como UserJob em segundo plano e agrupa correspondências de similaridade conectadas, em vez de mostrar apenas pares isolados. Depois da conclusão, carregue o resultado e revise nome, descrição, tipo, unidade e quantidade de Medições de cada registro. Resultados grandes são paginados, e o estado completo permanece em um cache temporário no servidor para evitar que o navegador reenvie todos os grupos a cada decisão.
Para cada membro do grupo, o curador escolhe:
Salvar decisões persiste os julgamentos de não duplicação e mantém as escolhas de mesclar e excluir disponíveis para execução. Marcar todos como não duplicados aplica esse julgamento a todos os membros, salva todas as decisões par a par e desabilita a execução, pois não resta ação operacional. Executar decisões primeiro inspeciona compatibilidade estrutural e autorização e então submete as mesclagens e exclusões definitivas selecionadas como UserJob. A detecção é deliberadamente mais ampla que a execução: Traits com unidades diferentes, por exemplo, podem ser detectados como possíveis duplicados, enquanto uma mesclagem insegura pode ser recusada até que as implicações de unidade e valores sejam resolvidas.
A decisão de não duplicação pertence ao par, não ao grupo inteiro. Varreduras futuras ignoram esse par. Se nome, descrição, tipo, unidade, categoria, limites, Trait pai ou outro campo conceitual relevante for alterado, as decisões relacionadas são invalidadas para permitir uma nova avaliação.
Traits, categorias de Traits, unidades de Traits, Tags, Projetos e Mídias possuem conteúdo traduzível criado pelos usuários. Quando um provedor de tradução está configurado, a navegação apresenta Missing translations (Traduções ausentes).
A tradução assistida pelo Google reduz o trabalho multilíngue repetitivo, mas
não é autoridade científica: prévias e resultados em lote precisam ser
revisados. Ela é opcional e fica indisponível enquanto
USER_TRANSLATION_PROVIDER estiver vazio.
A validação inicia um UserJob que verifica cada locale de conteúdo habilitado e informa campos ausentes que o usuário atual tem autorização para atualizar. Um campo sem texto de origem é informado, mas não pode ser gerado. A correção confere novamente o registro, a autorização, origem, destino, limite de caracteres e se outra pessoa já preencheu o texto antes de chamar o provedor e salvar o resultado. Sempre examine os resultados do UserJob e revise a terminologia científica gerada.
Os formulários também podem gerar campos ausentes durante a edição de um registro. A API de tradução oferece um endpoint de prévia e outro de gravação, permitindo que um cliente revise o conteúdo gerado antes de persistir.
Os endpoints POST e PUT de Traits não traduzem automaticamente os locales
ausentes. Eles armazenam somente as traduções enviadas explicitamente pelo
cliente; um PUT parcial preserva os locales omitidos. Essa separação evita que
uma importação publique silenciosamente terminologia não revisada.
A mesma busca por similaridade do formulário também protege POST e PUT da
API. Uma linha com possíveis duplicações é rejeitada com os identificadores dos
candidatos. Depois da revisão, um conceito realmente distinto pode ser reenviado
com confirm_similar_trait=true; essa confirmação é por linha e não deve ser
aplicada indiscriminadamente a toda uma importação.
Consulte também Traits e medições e Importar Traits com R.
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.
Use a identificação em lote quando vários Indivíduos compartilham a mesma determinação taxonômica. Antes de aplicar:
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.
Um Voucher representa uma amostra física de um Indivíduo depositada em uma BioColeção. Confira:
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.
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:
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.
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.
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.
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:
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.
Use este fluxo quando os Vouchers já existem em uma BioColeção gerenciada e você quer solicitar o material físico.
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.
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.
Os tutoriais aplicam os conceitos e guias de uso em fluxos reproduzíveis com o pacote OpenDataBio-R.
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.