Documentação

• 1: Visão geral
• 2: Primeiros passos
• 2.1: Primeira vez?
• 2.2: Instalação padrão
• 2.3: Instalação com Docker
• 2.4: Instalação com Nginx
• 2.5: Personalizar a instalação
• 2.6: Atualizar OpenDataBio
• 3: Guias de uso
• 3.1: Pesquisar e mapear dados
• 3.2: Fluxo de importação de dados
• 3.3: Organizar e publicar datasets
• 3.4: Importar filogenias para o backbone
• 3.5: Curadoria de bibliotecas compartilhadas
• 3.6: Vouchers, etiquetas e solicitações
• 3.7: Tutoriais
• 4: Serviços de API
• 4.1: Referência rápida
• 4.2: Obter dados - GET
• 4.3: Inserir dados - POST
• 4.4: Atualizar dados - PUT
• 5: Modelo conceitual
• 5.1: Objetos Centrais
• 5.2: Objetos de Atributos
• 5.3: Objetos de Acesso
• 5.4: Objetos Auxiliares
• 6: Como contribuir
• 7: Tutoriais
• 7.1: Obter dados via R
• 7.2: Importar dados via R
• 7.2.1: Importar Localidades
• 7.2.2: Importar BibReferences
• 7.2.3: Importar Vernacular
• 7.2.4: Importar Media
• 7.2.5: Importar Taxons
• 7.2.6: Importar Pessoas
• 7.2.7: Importar Variáveis
• 7.2.8: Importar Indivíduos & Vouchers
• 7.2.9: Importar Medições

1 - Visão geral

OpenDataBio é uma plataforma web de código aberto para organizar, relacionar, consultar, analisar e publicar dados de biodiversidade. Uma instalação pode ser usada por diferentes grupos de pesquisa, que compartilham bibliotecas comuns — como taxonomia, localidades, pessoas, referências e variáveis — sem perder o controle sobre a edição e a visibilidade de seus dados.

O que você pode fazer

Consultar, filtrar e mapear dados

Você pode consultar registros públicos sem iniciar uma sessão. As listas de registros, o Data Explorer e o Map Explorer permitem combinar filtros como dataset, projeto, grupo taxonômico e localidade. Resultados acessíveis podem ser inspecionados, mapeados e exportados.

Veja Pesquisar e mapear dados.

Registrar e relacionar dados de biodiversidade

Usuários autorizados podem registrar dados pela interface web, importar planilhas, usar a API ou coletar dados com formulários e o OpenDataBio Collect. O sistema relaciona:

• localidades, parcelas e transectos;
• taxons publicados e não publicados;
• indivíduos, suas localizações e seu histórico de identificações;
• vouchers e coleções biológicas;
• variáveis, medições e formulários;
• pessoas, referências bibliográficas, nomes populares e mídias.

Para começar, consulte Primeira vez?.

Organizar acesso e colaboração

Projetos reúnem usuários e datasets. Datasets organizam os registros que serão gerenciados e distribuídos juntos. Papéis como administrador, colaborador e visualizador determinam o que cada pessoa pode fazer em um projeto, dataset ou biocoleção; o nível global do usuário não substitui essas permissões.

Veja Papéis e permissões.

Publicar versões citáveis

Um dataset pode continuar recebendo correções e novos registros. Quando uma versão precisa ser distribuída ou citada, seus responsáveis podem criar um snapshot com UUID próprio, autores, licença, política de uso, citações, metadados e arquivos persistentes. Assim, a versão publicada permanece fixa enquanto o dataset continua evoluindo.

Veja Organizar e publicar datasets.

Trabalhar com taxonomia e identificações

OpenDataBio consulta serviços nomenclaturais durante o cadastro de taxons, permite revisar sugestões de validação e preserva o histórico biológico de identificações dos indivíduos.

Veja os Objetos centrais. Existe também um fluxo experimental para importar filogenias candidatas à incorporação no backbone, sujeito à revisão administrativa.

Automatizar importações e exportações

A API permite consultar, inserir e atualizar dados. O pacote OpenDataBio-R facilita essas operações em R. Importações e exportações grandes são executadas como UserJobs, com progresso, logs e resultados por registro.

Veja a API, os Fluxos de trabalho com R e a documentação de UserJobs.

Para administradores da instalação

Superadministradores mantêm usuários, serviços externos, registros do sistema, filas, armazenamento, backups e atualizações. Essas responsabilidades são diferentes da administração científica de um projeto ou dataset.

Consulte Instalação e administração e sempre leia o UPGRADES_NOTES.md da versão de destino antes de atualizar o sistema.

2 - Primeiros passos

OpenDataBio é um web-software para Linux nas distribuições Debian, Ubuntu e Arch-Linux e pode ser implementado em qualquer máquina baseada em Linux. Não temos planos de suporte ao Windows, mas pode ser fácil de instalar em uma máquina Windows usando o Docker.

OpenDataBio é escrito em PHP e desenvolvido com o framework Laravel. Requer um servidor web (Apache ou nginx), PHP e um banco de dados SQL - testado apenas com MySQL e MariaDB .

Você pode instalar o OpenDataBio facilmente usando os arquivos Docker incluídos na distribuição. O repositório agora inclui o perfil docker/prod e o arquivo docker-compose.prod.yml, permitindo uso com Docker também em produção (com ajustes de infraestrutura e segredos).

Se você deseja testar o OpenDataBio, ajudar no desenvolvimento ou ter uma instalação individual no seu computador, siga a instalação do Docker.

Proximos passos

1. Instalação padrão
2. Instalação com Nginx
3. Instalação com Docker
4. Atualizar OpenDataBio

Prepare para instalação

1. Você pode solicitar uma chave API Tropicos.org para que o OpenDataBio possa recuperar dados taxonômicos do banco de dados Tropicos.org. Se não for fornecido, principalmente o serviço de nomenclatura do GBIF será usado;
2. OpenDataBio envia e-mails para usuários registrados, seja para informar sobre um job que foi concluído, para enviar solicitações de dados para administradores de Conjuntos de Dados, ou para recuperação de senha. Você pode usar um e-mail do Google para isso, mas precisará alterar as opções de segurança da conta para permitir que o OpenDataBio use a conta para enviar e-mails (você precisa ativar a opção de Acesso a aplicativos menos seguros nas configurações da conta do gmail). Portanto, crie um endereço de e-mail dedicado para sua instalação. Verifique o arquivo “config/mail.php” para mais opções sobre como enviar e-mails.

2.1 - Primeira vez?

OpenDataBio é normalmente acessado em um servidor mantido por uma instituição ou grupo de pesquisa. As funcionalidades disponíveis dependem do seu nível de usuário e das permissões concedidas em cada projeto, dataset ou biocoleção.

Escolha seu ponto de partida

• Quero apenas consultar ou baixar dados: comece por Pesquisar e mapear dados.
• Quero inserir ou importar dados: leia Preparar uma conta de usuário pleno e depois escolha um dos fluxos de entrada de dados.
• Sou responsável por um dataset: leia Organizar e publicar datasets.
• Trabalho com vouchers ou uma biocoleção: consulte Vouchers, etiquetas e solicitações.
• Sou administrador da instalação: veja Responsabilidades do superadministrador e a seção de instalação e administração.

Papéis e permissões

Visitante

Sem iniciar uma sessão, um visitante pode consultar registros públicos, usar os exploradores, visualizar datasets e versões públicas e baixar dados cuja política permita acesso anônimo. Não pode inserir ou alterar registros.

Usuário registrado

O autocadastro cria uma conta básica. Um usuário registrado pode editar o próprio perfil e acessar dados disponibilizados para usuários autenticados. A instalação pode exigir autenticação e aceite de um acordo para determinados downloads. O cadastro, por si só, não autoriza a inserção de dados.

Usuário pleno

Um superadministrador, ou um usuário pleno autorizado a gerenciar acessos, pode promover uma conta registrada para usuário pleno. Esse nível permite criar dados e receber papéis de colaboração, mas cada operação continua dependendo das permissões do objeto. Ser usuário pleno não concede acesso a todos os datasets nem permite administrar a instalação.

Um usuário pleno pode, quando autorizado:

• criar registros nas bibliotecas compartilhadas;
• criar projetos e datasets;
• inserir dados pela interface ou por formulários;
• importar planilhas e usar a API;
• executar e acompanhar UserJobs;
• administrar objetos nos quais recebeu o papel apropriado.

Gestor de acesso de usuários

Um superadministrador pode conceder a um usuário pleno a permissão gerenciar acessos de usuários. Esse gestor pode:

• promover um usuário registrado para usuário pleno;
• rebaixar um usuário pleno para usuário registrado.

Essa delegação é limitada. O gestor de acesso não pode criar, promover ou remover superadministradores; não pode alterar outro gestor de acesso; e não pode conceder essa permissão a outras pessoas. Somente um superadministrador pode designar ou remover gestores de acesso.

Antes de promover uma conta, o gestor deve confirmar a identidade do usuário e seguir a política local da instalação. A promoção autoriza a criação de dados, mas não concede automaticamente participação em projetos, datasets ou biocoleções.

Administrador, colaborador e visualizador

Projetos, datasets e biocoleções possuem seus próprios participantes:

As regras específicas variam conforme o tipo de objeto. Por exemplo, o administrador de um dataset pode preparar versões e revisar suas políticas; o administrador de uma biocoleção controla os vouchers e solicitações sob a responsabilidade da coleção.

Superadministrador da instalação

O superadministrador tem acesso global e mantém a instalação. Ele deve:

• revisar novos usuários e atribuir níveis globais com cuidado;
• designar quais usuários plenos podem promover ou rebaixar contas;
• configurar integrações e serviços externos;
• habilitar biocoleções administradas pelo sistema;
• manter localidades e outros registros de referência do sistema;
• revisar ferramentas administrativas, como duplicidades e validações;
• monitorar filas, armazenamento, logs e backups;
• aplicar atualizações e os procedimentos do UPGRADES_NOTES.md.

O superadministrador não deve substituir os responsáveis científicos por projetos e datasets na curadoria cotidiana dos dados.

Preparar uma conta de usuário pleno

1. Confirme que sua conta foi promovida a usuário pleno.
2. Crie ou localize seu registro de Pessoa e associe-o como pessoa padrão do seu perfil. Isso permite preencher automaticamente autoria, coleta, medição e identificação quando apropriado.
3. Defina em qual projeto e dataset os novos registros serão organizados. Crie novos objetos apenas quando os existentes não representam o mesmo trabalho.
4. Consulte as regras locais da instalação para bibliotecas compartilhadas, evitando duplicar pessoas, taxons, localidades, referências ou variáveis.

Inserir e importar dados

Escolha o método conforme o volume e a maturidade dos seus dados:

1. Interface web: melhor para aprender o modelo, criar poucos registros e conferir validações.
2. Formulários: adequados para protocolos repetíveis de coleta e medição.
3. OpenDataBio Collect: usa formulários compatíveis para coleta móvel, inclusive offline.
4. Planilhas: permitem importação em lote pela interface. Os nomes das colunas correspondem aos parâmetros POST da API.
5. OpenDataBio-R: facilita preparar, validar, importar e consultar dados a partir do R.
6. API direta: indicada para integrações e clientes em outras linguagens.

Comece criando manualmente um exemplo pequeno de cada objeto necessário. Depois exporte ou consulte esse registro para confirmar nomes de campos, relações e identificadores antes de preparar um lote grande.

Ordem recomendada para novos dados

Cadastre ou localize primeiro as bibliotecas reutilizadas:

1. pessoas e referências bibliográficas;
2. taxons e localidades que ainda não existam;
3. traits, unidades, categorias e formulários;
4. projeto e dataset;
5. indivíduos e vouchers;
6. medições, identificações e mídias.

Uma localidade do tipo ponto não precisa ser criada antecipadamente quando a importação de indivíduos informa coordenadas e o fluxo utilizado permite sua criação automática. Parcelas, transectos e polígonos, entretanto, devem ser planejados e validados antes de importar grandes quantidades de indivíduos.

Antes de importar um lote grande

• teste algumas linhas pela interface ou em uma instalação de testes;
• confirme o dataset e as permissões de destino;
• valide datas, coordenadas e identificadores usados nas relações;
• separe nomes taxonômicos publicados de nomes não publicados;
• verifique se pessoas, referências e traits já existem;
• acompanhe o UserJob até o fim e examine avisos e erros por registro;
• exporte uma amostra após a importação para conferir o resultado.

Os tutoriais de R transformam essa sequência em exemplos reproduzíveis de consulta e importação. Antes deles, consulte o Fluxo de importação de dados para entender dependências, validação prévia de coordenadas, UserJobs e reconciliação de IDs.

2.2 - Instalação padrão

Estas instruções são para instalação baseada em apache. Para nginx, use Instalação com Nginx.

Requisitos do servidor

1. A versão suportada do PHP >= 8.2 (8.3 recomendado).
2. Servidor web: apache para este guia. Para nginx, use Instalação com Nginx.
3. Requer um banco de dados SQL, MySQL e MariaDB foram testados, mas também pode funcionar com Postgres. Testado com MySQL 8.0 e MariaDB 10.6+.
4. Extensões PHP necessárias: openssl, pdo, pdo_mysql, mbstring, tokenizer, xml, dom, gd, exif, bcmath, zip, curl, redis.
5. Redis Server é necessário para filas e cache.
6. Tectonic é usado para geração de PDFs/etiquetas a partir de LaTeX.
7. Pandoc é usado para traduzir o código LaTeX usado nas referências bibliográficas. Não é necessário para a instalação, mas é sugerido para uma melhor experiência do usuário.
8. Requer Supervisor, que é necessário para os jobs de usuário

Criar usuário dedicado

A maneira recomendada de instalar o OpenDataBio para produção é usando um usuário de sistema dedicado. Nestas instruções, esse usuário é odbserver.

Baixar OpenDataBio

Faça login como seu Usuário dedicado e baixe ou clone este software para onde deseja instalá-lo. Aqui assumimos que é /home/odbserver/opendatabio para que os arquivos de instalação residam neste diretório. Se este não for o seu caminho, altere abaixo sempre que aplicável.

Prepare o Servidor

Primeiro, instale os softwares Apache, MySQL, PHP, Redis, Tectonic, Pandoc e Supervisor. Em um sistema Debian, você também precisa instalar algumas extensões PHP e ativá-las:

#EXEMPLO EM UBUNTU 22.04

#repositórios
apt-get install software-properties-common
add-apt-repository ppa:ondrej/php
add-apt-repository ppa:ondrej/php ppa:ondrej/apache2
add-apt-repository ppa:ondrej/php
add-apt-repository ppa:ondrej/apache2
apt update

#instala o php
apt install php8.3 -y
apt update
apt upgrade

#instala extensoes (modulos) do php
php --version
#quais os modulos instalados?
php -m

#se algum desses nao estive, instale
apt install php8.3-{bcmath,xml,mysql,zip,intl,gd,cli,curl,mbstring,sqlite3,redis}

#install apache
apt install libapache2-mod-php8.3
#instala redis e tectonic
apt install redis-server tectonic
#install pandoc
apt install pandoc
#install supervisor (needed for jobs)
apt-get install supervisor -y

a2enmod php8.3
phpenmod mbstring
phpenmod xml
phpenmod dom
phpenmod gd
a2enmod rewrite
a2ensite
systemctl restart apache2.service

#To check if they are installed:
php -m | grep -E 'mbstring|cli|xml|gd|mysql|redis|bcmath|pcntl|zip'
tectonic --version
redis-server --version

Adicione o seguinte à sua configuração do Apache.

• Mude /home/odbserver/opendatabio para o seu caminho (os arquivos devem estar acessíveis pelo apache)
• Você pode criar um novo arquivo na pasta sites-available: /etc/apache2/sites-available/opendatabio.conf e colocar o seguinte código nele.

<IfModule alias_module>
        Alias /opendatabio      /home/odbserver/opendatabio/public/
        Alias /fonts /home/odbserver/opendatabio/public/fonts
        Alias /images /home/odbserver/opendatabio/public/images
        Alias /build /home/odbserver/opendatabio/public/build
        Alias /vendor/livewire /home/odbserver/opendatabio/public/vendor/livewire
        <Directory "/home/odbserver/opendatabio/public">
                Require all granted
                AllowOverride All
        </Directory>
</IfModule>

Isso fará com que o Apache redirecione todas as solicitações de / para a pasta correta, e também permitirá que o arquivo .htaccess fornecido controle as regras de reescrita, de forma que os URLs sejam bonitos. Se desejar acessar o arquivo apontando o navegador para a raiz do servidor, adicione também a seguinte diretiva:

RedirectMatch ^/$ /

Content Security Policy (CSP) para Apache

Configure o CSP na camada do servidor web (não nos arquivos Laravel). Aplique primeiro em modo report-only, valide os logs e depois migre para enforcement.

Para instalação standalone com nginx, use Instalação com Nginx.

Apache: onde colocar

1. Habilite o módulo necessário:

sudo a2enmod headers
sudo systemctl restart apache2

2. Edite o arquivo de vhost ativo (exemplo):

sudo nano /etc/apache2/sites-available/opendatabio.conf

3. Dentro do bloco <VirtualHost ...> correto (HTTP e/ou HTTPS), adicione:

Header always set Content-Security-Policy-Report-Only "
  default-src 'self';
  base-uri 'self';
  form-action 'self';
  frame-ancestors 'self';
  object-src 'none';
  script-src 'self' 'unsafe-eval';
  style-src 'self' 'unsafe-inline';
  img-src 'self' data: https://server.arcgisonline.com https://*.tile.openstreetmap.org;
  font-src 'self' data:;
  connect-src 'self';
"

4. Recarregue o Apache:

sudo apachectl configtest
sudo systemctl reload apache2

Instalações em subcaminho (/opendatabio)

Se sua instalação roda em subcaminho (por exemplo http://localhost/opendatabio), ajuste no .env:

APP_URL=http://localhost/opendatabio
ASSET_URL=http://localhost/opendatabio

Depois atualize os assets gerados e arquivos do Livewire:

php artisan livewire:publish --assets
php artisan optimize:clear
npm run build

Notas

1. https://server.arcgisonline.com e https://*.tile.openstreetmap.org são necessários para tiles do mapa.
2. unsafe-inline / unsafe-eval são flags temporárias de compatibilidade; remova após endurecer templates/assets.
3. Mantenha Report-Only enquanto ajusta a política em produção.

Configure seu arquivo php.ini. O instalador pode reclamar da falta de extensões do PHP, então lembre-se de ativá-las nos arquivos cli (/etc/php/8.3/cli/php.ini e web ini (/etc/php/8.3/fpm/php.ini) para PHP!

Atualize os valores para as seguintes variáveis:

Encontre os arquivos
php -i | grep 'Configuration File'

Mudar:
	memory_limit should be at least 512M
	post_max_size should be at least 30M
	upload_max_filesize should be at least 30M

Algo como:

[PHP]
allow_url_fopen=1
memory_limit = 512M

post_max_size = 100M
upload_max_filesize = 100M

Habilite os módulos Apache ‘mod_rewrite’ e ‘mod_alias’ e reinicie o servidor:

sudo a2enmod rewrite
sudo a2ensite
sudo systemctl restart apache2.service

Mysql Charset e Collation

1. Você deve adicionar o seguinte ao seu arquivo de configuração do SQL (mariadb.cnf ou my.cnf), ou seja, o conjunto de caracteres e o agrupamento que você escolher para sua instalação devem corresponder aos do config/database.php

[mysqld]
character-set-client-handshake = FALSE  #without this, there is no effect of the init_connect
collation-server      = utf8mb4_unicode_ci
init-connect          = "SET NAMES utf8mb4 COLLATE utf8mb4_unicode_ci"
character-set-server  = utf8mb4
log-bin-trust-function-creators = 1
sort_buffer_size = 256M  #espaco suficiente para consultas com geometria


[mariadb]
max_allowed_packet=100M
innodb_log_file_size=300M  #no use for mysql

2. Se estiver usando MariaDB e você ainda tiver problemas do tipo #1267 Illegal mix of collations, então verifique aqui sobre como consertar isso.

Configurar o supervisord

Configure o Supervisor, que é necessário para trabalhos. Crie um nome de arquivo opendatabio-worker.conf na pasta de configuração do Supervisor /etc/supervisor/ conf.d/opendatabio-worker.conf com o seguinte conteúdo, ajustando o caminho conforme a sua instalação:

touch /etc/supervisor/conf.d/opendatabio-worker.conf
echo ";--------------
[program:opendatabio-worker]
process_name=%(program_name)s_%(process_num)02d
command=php /home/odbserver/opendatabio/artisan queue:work --sleep=3 --tries=1 --timeout=0 --memory=512
autostart=true
autorestart=true
user=odbserver
numprocs=8
redirect_stderr=true
stdout_logfile=/home/odbserver/opendatabio/storage/logs/supervisor.log
;--------------" > /etc/supervisor/conf.d/opendatabio-worker.conf

Permissões de arquivos e pastas

• As pastas storage e bootstrap/cache precisam ter permissão de escrita para o usuário do servidor (geralmente www-data). Defina 0775 para esses diretórios.
• O arquivo de configuração .env precisa ter permissão 0640 pois contém senhas.
• Este link mostra diferentes métodos de definir permissões para um aplicativo Laravel.

Este é o método recomendado:

cd /home/odbserver

#note que odbserver e www-data podem mudar na sua configuracao

#defia as permissões tanto par ao seu usuário (aqui odbserver) como para o do apache (aqui www-data)
sudo chown -R odbserver:www-data opendatabio
sudo find ./opendatabio -type f -exec chmod 644 {} \;
sudo find ./opendatabio -type d -exec chmod 755 {} \;


cd /home/odbserver/opendatabio
sudo chgrp -R www-data storage bootstrap/cache
sudo chmod -R ug+rwx storage bootstrap/cache

#pasta media ajustar
sudo find ./storage/app/public/media  -type f -exec chmod 664 {} \;
sudo find ./storage/app/public/media  -type d -exec chmod 775 {} \;

#arquivo de configuracao .env para permissao 640 
sudo chmod 640 ./.env

Instale OpenDataBio

1. Muitas distribuições Linux (Ubuntu e Debian) têm arquivos php.ini diferentes para a interface de linha de comando e para o Apache. Recomenda-se usar o arquivo de configuração do Apache ao executar o script de instalação, para que ele possa apontar corretamente as extensões ou configurações ausentes. Para fazer isso, encontre o caminho correto para o arquivo .ini e exporte-o **antes de usar o comando de instalação php install **.

   Por exemplo,

   export PHPRC=/etc/php/8.3/apache2/php.ini
   

2. O script de instalação baixará o gerenciador de dependências Composer e todas as bibliotecas PHP necessárias listadas no arquivo composer.json. No entanto, se o seu servidor estiver atrás de um proxy, você deve instalar e configurar o Composer independentemente. Implementamos a configuração do PROXY, mas não a estamos mais usando e não testamos corretamente (se você precisar de ajustes, coloque um issue no GitLab).

3. O script solicitará opções de configuração, que são armazenadas no arquivo de ambiente .env na pasta raiz do aplicativo.

   Você pode, opcionalmente, configurar este arquivo antes de executar o instalador:

   • Crie um arquivo .env com o conteúdo do cp .env.example .env fornecido
   • Leia os comentários neste arquivo e ajuste de acordo
   • Garanta que ASSET_URL esteja correto para a URL/subcaminho da sua instalação

4. Execute o instalador:

cd /home/odbserver/opendatabio
php install

5. Compile os assets frontend depois de configurar o .env (obrigatorio quando ASSET_URL e adicionado ou alterado):

npm ci #talvez precise disso
npm run build

6. Seed data - o script irá pergunar se você quer instalar Localidades e Taxons distribuídos com aplicativo. Esses dados são específicos de cada versão do OpenDataBio. Ver as notas das versões no repositório desses dados.

Problemas de instalação

Existem inúmeras maneiras possíveis de instalar o aplicativo, mas podem envolver mais etapas e configurações.

• se o navegador retornar 500|SERVER ERROR , você deve olhar para o último error em storage/logs/laravel.log. Se você tiver ERROR: No application encryption key has been specified execute:

chave artesanal php: gerar
php artisan config: cache

• Se você receber o erro failed to open stream: Connection timed out durante a execução do instalador, isso indica uma configuração incorreta do seu roteamento IPv6. A correção mais fácil é desabilitar o roteamento IPv6 no servidor.
• Se você receber erros durante alimentação aleatória do banco de dados, você pode tentar remover o banco de dados inteiramente e reconstruí-lo. Claro, não execute isso em uma instalação de produção.

php artisan migrate: fresh

• Você pode substituir as tabelas Locations e Taxons usando o seed data depois de reconstruir a base:

php seedodb

Configurações pós-instalação

• Se seus Jobs de importação/exportação não estão sendo processados, certifique-se de que o Supervisor esteja executando systemctl start supervisord && systemctl enable supervisord e verifique os arquivos de log em storage/logs/supervisor.log.
• Você pode alterar várias variáveis ​​de configuração para o aplicativo. O mais importante deles provavelmente está definido pelo instalador, mas há outras variáveis em .env e no arquivo config/app.php que você pode alterar. Em particular, você pode querer alterar as configurações de idioma, fuso horário e e-mail. Execute php artisan config: cache após atualizar os arquivos de configuração.
• Para impedir que os rastreadores do mecanismo de pesquisa indexem seu banco de dados, adicione o seguinte ao seu “robots.txt” na pasta raiz do servidor (no Debian, /var/www/html):

User-agent: *
Disallow: /

• As pastas storage e bootstrap/cache devem ser graváveis ​​pelo usuário do Apache (geralmente www-data). Veja este link para um exemplo de como fazer isso. Defina a permissão 0775 para esses diretórios.

Atualizando uma instalação Apache existente

Antes de atualizar, faça backup do banco de dados, do arquivo .env e de storage/app/public/media. Antes de rodar os comandos, revise diferencas de configuracao da versao alvo:

• Compare .env com .env.example (incluindo assets_url)
• Confira configuracoes do PHP (php.ini em CLI e FPM/Apache)
• Confira configuracao dos workers no Supervisor

1. Coloque a aplicação em modo de manutenção:

cd /home/odbserver/opendatabio
php artisan down

2. Atualize o código-fonte para a versão desejada:

git fetch --tags
git checkout <tag-ou-branch-de-destino>

3. Atualize dependências e aplique migrações de banco:

composer install --no-dev --optimize-autoloader
php artisan migrate --force

4. Recompile os assets frontend apos mudancas no .env:

npm run build

5. Recrie os caches e reinicie os workers de fila:

php artisan optimize:clear
php artisan config:cache
php artisan queue:restart

6. Tire a aplicação do modo de manutenção:

php artisan up

Se a versão de destino incluir novas variáveis de ambiente, adicione-as ao .env antes de rodar assets/cache. Veja o conteúdo de .env.example para mudanças necessárias.

Armazenamento e backups

Você pode alterar as configurações de armazenamento em config/filesystem.php, onde pode definir o armazenamento baseado em nuvem, que pode ser necessário se muitos usuários enviarem arquivos de mídia, exigindo muito espaço em disco.

1. Downloads de dados são colocados em fila como Jobs e um arquivo é gravado em uma pasta temporária,sendo excluído quando o trabalho é excluído pelo usuário. Esta pasta é definida como download disk no arquivo de configuração filesystem.php, que aponta para storage/app/public/downloads. Apagar esses arquivos temporários depende dos usuários, portanto, um trabalho de limpeza do cron pode ser aconselhável para implementar em sua instalação;
2. Arquivos de mídia são armazenados por padrão no media disk, que coloca os arquivos na pasta storage/app/ public/media;
3. Para configuração regular crie ambos os diretórios storage/app/public/downloads e storage/app/public/media com permissões graváveis ​​pelo usuário do servidor
4. Lembre-se de incluir a pasta de mídia em um plano de backup;

2.3 - Instalação com Docker

A maneira mais fácil de instalar e executar o OpenDataBio é usando o Docker e os arquivos de configuração do docker fornecidos, que contêm todas as configurações necessárias para executar o ODB. Usa nginx e mysql e supervisor.

Perfil de produção

O OpenDataBio agora inclui um perfil Docker orientado a produção:

• docker/prod/nginx.conf
• docker/prod/php.ini
• docker/prod/www.conf
• docker-compose.prod.yml

Execute o compose de produção com:

docker compose -f docker-compose.prod.yml build
docker compose -f docker-compose.prod.yml up -d

Principais diferenças em relação ao dev:

1. Usa configurações nginx/php-fpm em docker/prod/*.
2. Remove bind-mounts do código-fonte da aplicação.
3. Desativa o phpMyAdmin por padrão (perfil dev-only).
4. Publica o nginx na porta 80 (ajuste se houver reverse proxy).

O CSP no nginx (report-only) está incluído em docker/prod/nginx.conf. Mantenha report-only primeiro e só depois aplique enforcement.

Arquivos Docker incluídos

laravel-app/
----docker/*
----.env.docker
----docker-compose.yml
----Dockerfile
----Makefile

Eles foram adaptados deste link, onde você também encontra uma configuração de produção.

Instalação

Pré-requisitos

1. Docker com plugin Compose (docker compose v2).
2. Linux/mac: usuário no grupo docker ou usar sudo.
3. Windows: Docker Desktop (WSL2/Hyper-V habilitados).

Início rápido (Linux/mac, requer make)

cd opendatabio
make docker-init          # copia .env.docker se faltar, sobe containers, instala composer, gera key, migra e faz storage:link
make seed-odb             # seed opcional para Locations/Taxons
#ou tudo junto
make docker-init SEED=1   # igual acima + seed opcional para Locations/Taxons

• Depois de configurar o .env (ou sempre que ASSET_URL mudar), recompile os assets:

npm run build

• App: http://localhost:8081 (usuário admin@example.org / password1)
• phpMyAdmin: http://localhost:8082

Windows (PowerShell)

cd opendatabio
powershell -ExecutionPolicy Bypass -File scripts/docker-init.ps1
# opcional seed
powershell -ExecutionPolicy Bypass -File scripts/docker-init.ps1 -Seed

Comandos manuais (se você não tiver make)

cp .env.docker .env
docker compose up -d
docker compose exec -T -u www-data laravel composer install --optimize-autoloader
docker compose exec -T -u www-data laravel php artisan key:generate --force
docker compose exec -T -u www-data laravel php artisan migrate --force
docker compose exec -T -u www-data laravel php artisan storage:link

Seed opcional sem make:

docker compose exec -T -u www-data laravel php getseeds
docker exec -i odb_mysql mysql -uroot -psecret odbdocker < storage/Location*.sql
docker exec -i odb_mysql mysql -uroot -psecret odbdocker < storage/Taxon*.sql
rm storage/Location*.sql storage/Taxon*.sql

Persistência de dados

Os contêineres criados pelo Docker podem ser excluídos e recriados sem perder os dados As tabelas MySQL são armazenadas em um volume; se ele for apagado, a base de dados será excluída.

docker volume list

Usando

O arquivo Makefile contém os seguintes comandos para interagir com os contêineres do docker e o odb.

Comandos para construir e criar o app

1. make docker-init - copia .env.docker (se faltar), constroi/sobe containers, instala composer, gera key, migra e faz storage:link
2. make build - construir os contêineres
3. make key-generate - gerar a chave do app e adicioná-la ao .env
4. make composer-install - instalar dependências php
5. make composer-update - atualizar dependências php
6. make composer-dump-autoload - executar o dump-autoload do composer dentro do contêiner
7. make migrate - criar ou atualizar o banco de dados
8. make drop-migrate - apaga a base de dados e migra novamente
9. make seed-odb - popular o banco de dados com localizações e táxons

Comandos para acessar os contêineres docker

1. make start - iniciar todos os contêineres
2. make stop - parar todos os contêineres
3. make restart - reiniciar todos os contêineres
4. make ssh - entrar no contêiner principal da aplicação laravel
5. make ssh-mysql - entrar no contêiner mysql, para que você possa acessar o log do banco de dados usando mysql -uUSER -pPWD
6. make mysql - entrar no console docker do mysql
7. make ssh-nginx - entrar no contêiner nginx
8. make ssh-supervisord - entrar no contêiner supervisord

Comandos de manutenção

1. make optimize - limpar caches e arquivos de log
2. make info - mostrar informações do app
3. make logs - mostrar logs do laravel
4. make logs-mysql - mostrar logs do mysql
5. make logs-nginx - mostrar logs do nginx
6. make logs-supervisord - mostrar logs do supervisord

Recriando os containers

Se você tiver problemas e alterou os arquivos do docker, pode ser necessário reconstruir:

#apaga todas as imagens sem apagr a base de dados
make stop #pare todas
docker system prune -a  #aceitar com Yes

#se quiser pagar os dados
docker volume list
docker volume rm VOLUME_ID

#construa novamente
make build
make start

Atualizando uma instalação Docker existente

Antes de atualizar, faça backup do banco de dados e de storage/app/public/media. Antes de rodar os comandos, revise diferencas de configuracao da versao alvo:

• Compare .env com .env.example (incluindo assets_url)
• Confira configuracoes PHP do perfil alvo (docker/prod/php.ini ou seu arquivo customizado)
• Confira configuracao do Supervisor (docker/supervisord.conf ou equivalente no seu deploy)

1. Atualize o código-fonte para a versão desejada:

cd opendatabio
git fetch --tags
git checkout <tag-ou-branch-de-destino>

2. Reconstrua e reinicie os contêineres:

make stop
make build
make start

3. Atualize dependências PHP e rode as migrações:

make composer-install
make migrate

4. Recompile os assets frontend apos mudancas no .env:

npm run build

5. Atualize os caches do Laravel e reinicie os workers de fila:

make optimize
docker compose exec -T -u www-data laravel php artisan queue:restart

Se a nova versão incluir mudanças no .env, adicione as novas chaves antes de rodar assets/cache/restart em produção.

2.4 - Instalação com Nginx

Estas instruções são para instalação com nginx. Se preferir Apache, use a página de instalação padrão (Apache).

Requisitos do servidor

1. Versão suportada do PHP >= 8.2 (8.3 recomendado).
2. Servidor web: nginx.
3. Banco SQL: MySQL ou MariaDB (testado com MySQL 8.0 e MariaDB 10.6+).
4. Extensões PHP necessárias: openssl, pdo, pdo_mysql, mbstring, tokenizer, xml, dom, gd, exif, bcmath, zip, curl, redis.
5. Redis para filas/cache.
6. Tectonic para geração de PDF de etiquetas.
7. Pandoc para renderização bibliográfica (recomendado).
8. Supervisor para jobs em segundo plano.

Configuração do site no nginx

Crie o arquivo do site (exemplo):

sudo nano /etc/nginx/sites-available/opendatabio

Use este bloco base (ajuste domínio/caminhos):

server {
    listen 80;
    server_name seu-dominio.exemplo;

    root /home/odbserver/opendatabio/public;
    index index.php index.html;

    charset utf-8;
    client_max_body_size 300M;

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

    location ~ \.php$ {
        try_files $uri =404;
        fastcgi_split_path_info ^(.+\.php)(/.+)$;
        fastcgi_pass unix:/var/run/php/php8.3-fpm.sock;
        fastcgi_index index.php;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_param PATH_INFO $fastcgi_path_info;
        fastcgi_read_timeout 300;
    }

    location ~ /\. {
        deny all;
    }
}

Ative e recarregue:

sudo ln -s /etc/nginx/sites-available/opendatabio /etc/nginx/sites-enabled/opendatabio
sudo nginx -t
sudo systemctl reload nginx

Content Security Policy (CSP)

No mesmo arquivo do site nginx, adicione no bloco server { ... }:

add_header Content-Security-Policy-Report-Only "
  default-src 'self';
  base-uri 'self';
  form-action 'self';
  frame-ancestors 'self';
  object-src 'none';
  script-src 'self' 'unsafe-eval';
  style-src 'self' 'unsafe-inline';
  img-src 'self' data: https://server.arcgisonline.com https://*.tile.openstreetmap.org;
  font-src 'self' data:;
  connect-src 'self';
" always;

Depois recarregue:

sudo nginx -t
sudo systemctl reload nginx

Notas:

1. Comece com Report-Only e depois migre para enforcement após validar logs.
2. https://server.arcgisonline.com e https://*.tile.openstreetmap.org são necessários para os tiles do mapa.

Instalações em subcaminho (/opendatabio)

Se sua instalação roda em subcaminho (por exemplo http://localhost/opendatabio), ajuste no .env:

APP_URL=http://localhost/opendatabio
ASSET_URL=http://localhost/opendatabio

Depois atualize os assets gerados e arquivos do Livewire:

php artisan livewire:publish --assets
php artisan optimize:clear
npm run build

Etapas compartilhadas da aplicação

Para evitar redundância, use as mesmas seções da instalação Apache (também válidas para implantação com nginx):

1. Configurações de PHP (php.ini) em Instalação padrão
2. Configurar o supervisord em Instalação padrão
3. Permissões de arquivos e pastas em Instalação padrão
4. Instale OpenDataBio em Instalação padrão
5. Configurações pós-instalação em Instalação padrão

2.5 - Personalizar a instalação

Mudanças simples que podem ser implementadas no layout de um site OpenDataBio

Logo e imagem de fundo

Para substituir o logotipo da barra de navegação e a imagem da página inicial, apenas coloque seus arquivos de imagem substituindo os arquivos em /public/custom/ sem alterar seus nomes.

Textos e informações

Para alterar o texto de boas-vindas da página inicial, altere os valores para cada entrada nos arquivos:

• /resources/lang/en/customs.php
• /resources/lang/pt-br/customs.php
• Não remova as chaves de entrada. Defina como null para suprimir a exibição no rodapé e na página inicial.

Documentação Local

Você pode adicionar documentação em formato *.md para o repositório em arquivos nas seguintes pastas:

• /resources/docs/en/*
• /resources/docs/pt/*

Este espaço é reservado para administradores definirem documentação e diretivas personalizadas para os usuários de uma instalação específica do OpenDataBio. Por exemplo, este é um espaço para adicionar um código de conduta para os usuários, quem contatar para se tornar um usuário pleno,tutoriais específicos, etc.

NavBar e Rodapé

1. Se você deseja alterar a cor da barra de navegação superior e do rodapé, basta substituir a classe css Boostrap 5 nas tags e arquivos correspondentes na pasta /resources/view/layout.
2. Você pode adicionar html adicional ao rodapé e barra de navegação, alterar o tamanho do logotipo, etc… como desejar.

2.6 - Atualizar OpenDataBio

Use esta página para a sequência comum de implantação. Antes de atualizar, leia o arquivo UPGRADES_NOTES.md da versão de destino do OpenDataBio. Ele é a fonte oficial para requisitos, permissões de armazenamento, migrações, preenchimentos e comandos de reparo específicos da versão; essas instruções não são repetidas aqui.

Antes de começar

1. Leia UPGRADES_NOTES.md e as notas da versão de destino. Anote todos os testes preliminares e comandos pós-migração antes de começar.
2. Faça backup de pelo menos:
   • Dump do banco de dados
   • .env
   • Toda a árvore storage/app, incluindo mídias, exportações geradas e os arquivos persistentes das versões de datasets
3. Compare as configurações atuais com os modelos/configurações da versão de destino:
   • .env com .env.example (incluindo ASSET_URL)
   • Configuração do Supervisor (/etc/supervisor/conf.d/opendatabio-worker.conf ou equivalente no contêiner)
   • Configuração do PHP (php.ini de CLI e FPM/Apache)
4. Planeje uma janela de manutenção para o ambiente de produção.

Atualização (instalação Apache ou nginx)

1. Coloque a aplicação em modo de manutenção:

cd /home/odbserver/opendatabio
php artisan down

2. Atualize o código-fonte:

git fetch --tags
git checkout <target-tag-or-branch>

3. Instale as dependências e execute as migrações:

composer install --no-dev --optimize-autoloader
php artisan migrate:status
php artisan migrate --force

4. Execute, na ordem documentada, os comandos pós-migração indicados no UPGRADES_NOTES.md da versão de destino. Alguns comandos enviam UserJobs em segundo plano; mantenha a aplicação em manutenção e acompanhe-os até o fim quando as notas assim exigirem.
5. Recompile os assets do frontend após mudanças no .env (obrigatório quando ASSET_URL mudar):

npm ci
npm run build

6. Limpe o cache e reinicie os workers:

php artisan optimize:clear
php artisan config:cache
php artisan queue:restart
systemctl restart supervisor.service
# Reinicie o servidor web e o PHP-FPM conforme a sua instalação.

7. Verifique a aplicação, os workers, os logs e as operações citadas nas notas de atualização; depois coloque a aplicação online novamente:

php artisan up

Atualização (instalação Docker)

1. Atualize o código-fonte:

cd opendatabio
git fetch --tags
git checkout <target-tag-or-branch>

2. Reconstrua e reinicie os contêineres:

make stop
make build
make start

3. Instale as dependências e execute as migrações:

make composer-install
make migrate

4. Execute dentro do contêiner da aplicação, na ordem documentada, os comandos pós-migração do UPGRADES_NOTES.md da versão de destino e acompanhe os UserJobs enviados por eles.
5. Recompile os assets do frontend após mudanças no .env (obrigatório quando ASSET_URL mudar):

npm run build

6. Limpe o cache e reinicie os workers:

make optimize
docker compose exec -T -u www-data laravel php artisan queue:restart

Variáveis de ambiente

Compare .env com o .env.example da versão de destino antes de compilar assets ou armazenar configurações em cache. Siga UPGRADES_NOTES.md para variáveis cujo valor ou significado mudou; em produção, confira APP_FORCE_HTTPS e ASSET_URL.

Estratégia de rollback

Se algo falhar depois das migrações:

1. Mantenha o modo de manutenção ativo.
2. Restaure o banco, o .env e o backup correspondente de storage/app. Os registros do banco e os arquivos das versões de datasets devem ser restaurados como um único snapshot.
3. Retorne para a tag estável anterior.
4. Reinstale as dependências/reconstrua os contêineres e valide os logs antes de php artisan up.

3 - Guias de uso

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.

3.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.

3.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.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.

3.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.

3.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.

3.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.

3.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.

4 - Serviços de API

Cada instalação do OpenDataBio fornece um serviço de API, permitindo aos usuários OBTER, INSERIR, ATUALIZAR dados programaticamente. O serviço é de acesso aberto a dados públicos, e requer autenticação do usuário para INSERIR e ATUALIZAR dados, ou para OBTER dados de acesso restrito.

O pacote OpenDataBio é um cliente para esta API, permitindo a interação com o repositório de dados diretamente do R.

A API OpenDataBio permite a consulta ao banco de dados e a importação/edição de dados por meio de uma interface inspirada em REST.

Todas as solicitações e respostas da API são formatadas em JSON.

A interação com a API do OpenDataBio

Uma simples chamada para a API OpenDataBio possui quatro partes independentes:

1. HTTP-verbo - GET para exportações, POST para importações e PUT para atualizações.
2. URL-base - o URL usado para acessar seu servidor OpenDataBio + mais / api / v0. Por exemplo, http:// opendatabio.inpa.gov.br/api/v0
3. endpoint - representa o objeto ou coleção de objetos que você deseja acessar, por exemplo, para consultar nomes taxonômicos, o endpoint é “taxons”
4. parâmetros de solicitação - representam a filtragem e o processamento que devem ser feitos com os objetos e são representados na chamada da API após um ponto de interrogação. Por exemplo, para recuperar apenas nomes taxonômicos válidos finalize a solicitação com ?valid = 1.

A chamada API acima pode ser inserida em um navegador para OBTER dados de acesso público. Por exemplo, para obter a lista de táxons válidos de uma instalação do OpenDataBio, a solicitação da API poderia ser:

https://opendb.inpa.gov.br/api/v0/taxons?valid=1&limit=10

Quando usar o OpenDataBio R package essa mesma chamada seria algo como odb_get_taxons(list(valid=1,limit=10)).

A resposta será algo como:

{
  "meta":
  {
    "odb_version":"0.9.1-alpha1",
    "api_version":"v0",
    "server":"http://opendb.inpa.gov.br",
    "full_url":"https://opendb.inpa.gov.br/api/v0/taxons?valid=1&limit1&offset=100"},
    "data":
    [
      {
        "id":62,
        "parent_id":25,
        "author_id":null,
        "scientificName":"Laurales",
        "taxonRank":"Ordem",
        "scientificNameAuthorship":null,
        "namePublishedIn":"Juss. ex Bercht. & J. Presl. In: Prir. Rostlin: 235. (1820).",
        "parentName":"Magnoliidae",
        "family":null,
        "taxonRemarks":null,
        "taxonomicStatus":"accepted",
        "ScientificNameID":"http:\/\/tropicos.org\/Name\/43000015 | https:\/\/www.gbif.org\/species\/407",
        "basisOfRecord":"Taxon"
    }]}

Autenticação da API

1. Não é obrigatória para obter quaisquer dados de acesso público numa base de dados ODB, que por padrão inclui Localidades, Taxons, Referências Bibliográficas, Pessoas e Variáveis.
2. Autenticação é necessária para OBTER quaisquer dados que não sejam de acesso público e para INSERIR e ATUALIZAR dados.

• A autenticação é feita usando um token API, que pode ser encontrado no seu perfil de usuário na interface do aplicativo. O token é atribuído a um único usuário do banco de dados e não deve ser compartilhado, exposto, enviado por e-mail ou armazenado em controles de versão.
• Para autenticar na API OpenDataBio, use o token no cabeçalho “Authorization” da solicitação da API.

Os usuários terão acesso somente aos dados para os quais o usuário tem permissão e para quaisquer dados com acesso público na base de dados. O acesso à Medições, Indivíduos, Vouchers e Mídia depende das permissões compreendidas pelo token do usuário.

Versões da API

A API OpenDataBio segue seu próprio número de versão. Isso significa que o cliente pode esperar usar o mesmo código e obter as mesmas respostas, independentemente da versão do OpenDataBio que o servidor está executando. Todas as alterações feitas na mesma versão da API devem ser compatíveis com versões anteriores. Nosso controle de versão da API é controlado pelo URL, portanto, para solicitar uma versão específica da API, use o número da versão entre o URL base e o endpoint:

https://opendb.inpa.gov.br/api/v1/taxons

https://opendb.inpa.gov.br/api/v2/taxons

4.1 - Referência rápida

OBTER DADOS - GET

Parâmetros GET compartilhados

Parâmetros GET específicos

Importar ou Validar dados - POST

Atualizar dados - PUT

Nomenclature Types

Níveis taxonômicos (Ranks)

4.2 - Obter dados - GET

Parâmetros GET compartilhados

Selecionar campos da resposta

O parâmetro fields controla as colunas retornadas:

• simple é o perfil padrão e reúne os campos mais úteis para o uso comum;
• all inclui campos adicionais, técnicos, relacionais ou mantidos por compatibilidade;
• uma lista separada por vírgulas, como fields=id,uuid,scientificName, retorna apenas os campos solicitados.

Cada endpoint abaixo apresenta uma tabela com os campos de simple e all e o significado de cada coluna. As descrições vêm do mesmo schema usado pela aplicação. Quando um campo muda de sentido conforme o endpoint — por exemplo, x e y em Localidades e Indivíduos — a definição específica do endpoint é mostrada. Campos indicados como Darwin Core seguem o vocabulário de intercâmbio; campos indicados como locais são extensões do OpenDataBio.

Endpoints GET

Links rápidos

• /
• bibreferences
• biocollections
• datasets
• individuals
• individual-locations
• languages
• locations
• measurements
• media
• persons
• projects
• taxons
• traits
• vernaculars
• vouchers
• userjobs
• activities
• tags
• brahms
• identification-histories

/ (GET)

Testa seu acesso/token.

Nenhum parâmetro para este endpoint.

bibreferences (GET)

Referências bibliográficas (GET lista, POST cria).

Campos retornados

O perfil simple é a resposta padrão; all acrescenta campos detalhados, técnicos ou de compatibilidade. Use o parâmetro fields para solicitar uma lista explícita.

Exemplo de resposta

{
    "meta": {
        "odb_version": "0.10.0-alpha1",
        "api_version": "v0",
        "server": "http://localhost/opendatabio"
    },
    "data": [
        {
            "id": 2,
            "bibkey": "Riberiroetal1999FloraDucke",
            "year": 1999,
            "author": "José Eduardo Lahoz Da Silva Ribeiro and Michael John Gilbert Hopkins and Alberto Vicentini and Cynthia Anne Sothers and Maria Auxiliadora Da Silva Costa and Joneide Mouzinho De Brito and Maria Anália Duarte De Souza and Lúcia Helena Pinheiro Martins and Lúcia Garcez Lohmann and Paulo Apóstolo Costa Lima Assunção and Everaldo Da Costa Pereira and Cosme Fernandes Da Silva and Mariana Rabello Mesquita and Lilian Costa Procópio",
            "title": "Flora Da Reserva Ducke: Guia De Identificação Das Plantas Vasculares De Uma Floresta De Terra Firme Na Amazônica Central",
            "doi": null,
            "url": null,
            "bibtex": "@Article{Riberiroetal1999FloraDucke,\r\n  title = {Flora da Reserva Ducke: Guia de Identifica{\\c{c}}{\\~a}o das Plantas Vasculares de uma Floresta de Terra Firme na Amaz{\\^o}nica Central},\r\n  author = {José Eduardo Lahoz da Silva Ribeiro and Michael John Gilbert Hopkins and Alberto Vicentini and Cynthia Anne Sothers and Maria Auxiliadora da Silva Costa and Joneide Mouzinho de Brito and Maria Anália Duarte de Souza and Lúcia Helena Pinheiro Martins and Lúcia Garcez Lohmann and Paulo Apóstolo Costa Lima Assunç{ã}o and Everaldo da Costa Pereira and Cosme Fernandes da Silva and Mariana Rabello Mesquita and Lilian Costa Procópio},\r\n  journal = {Flora da Reserva Ducke: Guia de Identifica{\\c{c}}{\\~a}o das Plantas Vasculares de uma Floresta de Terra Firme na Amaz{\\^o}nica Central},\r\n  year = {1999},\r\n  publisher = {INPA-DFID Manaus},\r\n  pages = {819p},\r\n}"
        },
        {
            "id": 3,
            "bibkey": "Sutter2006female",
            "year": 2006,
            "author": "D. Merino Sutter and P. I. Forster and P. K. Endress",
            "title": "Female Flowers And Systematic Position Of Picrodendraceae (Euphorbiaceae S.l., Malpighiales)",
            "doi": "10.1007/s00606-006-0414-0",
            "url": "http://dx.doi.org/10.1007/s00606-006-0414-0",
            "bibtex": "@article{Sutter2006female,\n     author = {D. Merino Sutter and P. I. Forster and P. K. Endress},\n     year = {2006},\n     title = {Female flowers and systematic position of Picrodendraceae (Euphorbiaceae s.l., Malpighiales)},\n     issn = {0378-2697 | 1615-6110},\n     issue = {1-4},\n     url = {http://dx.doi.org/10.1007/s00606-006-0414-0},\n     doi = {10.1007/s00606-006-0414-0},\n     volume = {261},\n     page = {187-215},\n     journal = {Plant Systematics and Evolution},\n     journal_short = {Plant Syst. Evol.},\n     published = {Springer Science and Business Media LLC}\n}"
        }
    ]
}

biocollections (GET)

Biocoleções (GET lista, POST cria).

Campos retornados

O perfil simple é a resposta padrão; all acrescenta campos detalhados, técnicos ou de compatibilidade. Use o parâmetro fields para solicitar uma lista explícita.

Exemplo de resposta

{
    "meta": {
        "odb_version": "0.10.0-alpha1",
        "api_version": "v0",
        "server": "http://localhost/opendatabio"
    },
    "data": [
        {
            "id": 1,
            "acronym": "INPA",
            "name": "Instituto Nacional de Pesquisas da Amazônia",
            "irn": 124921,
            "country": null,
            "city": null,
            "address": null
        },
        {
            "id": 2,
            "acronym": "SPB",
            "name": "Universidade de São Paulo",
            "irn": 126324,
            "country": null,
            "city": null,
            "address": null
        }
    ]
}

datasets (GET)

Datasets e versões publicadas de datasets (GET lista, POST cria via job de importação).

Campos retornados

O perfil simple é a resposta padrão; all acrescenta campos detalhados, técnicos ou de compatibilidade. Use o parâmetro fields para solicitar uma lista explícita.

Exemplo de resposta

{
    "meta": {
        "odb_version": "0.10.0-alpha1",
        "api_version": "v0",
        "server": "http://localhost/opendatabio"
    },
    "data": [
        {
            "id": 4,
            "name": "PDBFF-FITO 1ha core plots 1-10cm dbh - TREELETS",
            "title": "Arvoretas (1cm>DAP",
            "projectName": "Projeto Dinâmica Biológica de Fragmentos Florestais (PDBFF-Data)",
            "notes": null,
            "privacyLevel": "Restrito a usuários autorizados",
            "policy": null,
            "description": "Contém o único censo de árvores de pequeno porte 1-10cm de diâmetro nas parcelas de 1ha do PDBFF, em 11 das 69 de parcelas permanentes de 1ha do Programa de Monitoramento de Plantas do PDBFF.",
            "measurements_count": null,
            "contactEmail": "example",
            "taggedWidth": "Parcelas florestais | PDBFF | Fitodemográfico",
            "uuid": "e1d8ce8d-4847-11f0-8e9f-9cb654b86224"
        }
    ]
}

individuals (GET)

Indivíduos (GET lista, POST cria, PUT atualiza).

Campos retornados

O perfil simple é a resposta padrão; all acrescenta campos detalhados, técnicos ou de compatibilidade. Use o parâmetro fields para solicitar uma lista explícita.

Exemplo de resposta

{
    "meta": {
        "odb_version": "0.10.0-alpha1",
        "api_version": "v0",
        "server": "http://localhost/opendatabio"
    },
    "data": [
        {
            "id": 306246,
            "basisOfRecord": "Organism",
            "organismID": "2639_Spruce_1852",
            "recordedByMain": "Spruce, R.",
            "recordNumber": "2639",
            "recordedDate": "1852-10",
            "recordedBy": "Spruce, R.",
            "scientificName": "Ecclinusa lanceolata",
            "scientificNameAuthorship": "(Mart. & Eichler) Pierre",
            "taxonPublishedStatus": "published",
            "genus": "Ecclinusa",
            "family": "Sapotaceae",
            "identificationQualifier": "",
            "identifiedBy": "Spruce, R.",
            "dateIdentified": "1852-10-00",
            "identificationRemarks": "",
            "identificationBiocollection": null,
            "identificationBiocollectionReference": null,
            "locationName": "São Gabriel da Cachoeira",
            "higherGeography": "São Gabriel da Cachoeira < Amazonas < Brasil",
            "decimalLatitude": 1.1841927,
            "decimalLongitude": -66.80167715,
            "georeferenceRemarks": "decimal coordinates are the CENTROID of the footprintWKT geometry",
            "locationParentName": "Amazonas",
            "x": null,
            "y": null,
            "gx": null,
            "gy": null,
            "angle": null,
            "distance": null,
            "organismRemarks": "prope Panure ad Rio Vaupes Amazonas, Brazil",
            "datasetName": "Exsicatas LABOTAM",
            "uuid": "c01000f0-f437-11ef-b90b-9cb654b86224"
        }
    ]
}

individual-locations (GET)

Ocorrências para indivíduos com múltiplas localizações (GET lista, POST/PUT grava).

Campos retornados

O perfil simple é a resposta padrão; all acrescenta campos detalhados, técnicos ou de compatibilidade. Use o parâmetro fields para solicitar uma lista explícita.

Exemplo de resposta

{
    "meta": {
        "odb_version": "0.10.0-alpha1",
        "api_version": "v0",
        "server": "http://localhost/opendatabio"
    },
    "data": [
        {
            "id": 306244,
            "individual_id": 306246,
            "basisOfRecord": "Occurrence",
            "occurrenceID": "2639_Spruce_1852.1852-10",
            "organismID": "2639_Spruce_1852",
            "scientificName": "Ecclinusa lanceolata",
            "family": "Sapotaceae",
            "recordedDate": "1852-10",
            "locationName": "São Gabriel da Cachoeira",
            "higherGeography": "Brasil > Amazonas > São Gabriel da Cachoeira",
            "decimalLatitude": 1.1841927,
            "decimalLongitude": -66.80167715,
            "georeferenceRemarks": "decimal coordinates are the CENTROID of the footprintWKT geometry",
            "x": null,
            "y": null,
            "angle": null,
            "distance": null,
            "minimumElevation": null,
            "occurrenceRemarks": null,
            "organismRemarks": "prope Panure ad Rio Vaupes Amazonas, Brazil",
            "datasetName": "Exsicatas LABOTAM"
        }
    ]
}

languages (GET)

Lista idiomas disponíveis.

Exemplo de resposta

{
    "meta": {
        "odb_version": "0.10.0-alpha1",
        "api_version": "v0",
        "server": "http://localhost/opendatabio"
    },
    "data": [
        {
            "id": 1,
            "code": "en",
            "name": "English",
            "is_locale": 1,
            "created_at": null,
            "updated_at": null
        }
    ]
}

locations (GET)

Localidades (GET lista, POST cria, PUT atualiza).

Campos retornados

O perfil simple é a resposta padrão; all acrescenta campos detalhados, técnicos ou de compatibilidade. Use o parâmetro fields para solicitar uma lista explícita.

Exemplo de resposta

{
    "meta": {
        "odb_version": "0.10.0-alpha1",
        "api_version": "v0",
        "server": "http://localhost/opendatabio"
    },
    "data": [
        {
            "id": 27297,
            "basisOfRecord": "Location",
            "locationName": "Parcela 1105",
            "adm_level": 100,
            "country_adm_level": "Parcela",
            "x": "100.00",
            "y": "100.00",
            "startx": null,
            "starty": null,
            "distance_to_search": null,
            "parent_id": 27277,
            "parentName": "Fazenda Esteio",
            "higherGeography": "Brasil > Amazonas > Rio Preto da Eva > Fazenda Esteio > Parcela 1105",
            "footprintWKT": "POLYGON((-59.81371985 -2.42215752,-59.81360263 -2.42126619,-59.81270751 -2.42136656,-59.81282469 -2.42225788,-59.81371985 -2.42215752))",
            "locationRemarks": "source: Polígono desenhado a partir das coordenadas de GPS dos vértices; georeferencedBy: Diogo Martins Rosa & Ana Andrade; fundedBy: Edital CNPq-Brasil/LBA 458027/2013-8; geometryBy: Alberto Vicentini; geometryDate: 2021-09-29; warning: Conflito com polígono da UC de 2021. Este polígono deveria ter a mesma geometria do polígono correspondente que faz parte da UC ARIE PDBFF, mas como ele foi gerado pelas coordenadas de campo, foi mantida essa geometria. A UC, portanto, não protege adequadamente essa parcela de monitoramento.",
            "decimalLatitude": -2.42215752,
            "decimalLongitude": -59.81371985,
            "georeferenceRemarks": "decimal coordinates are the START POINT in footprintWKT geometry",
            "geodeticDatum": null
        }
    ]
}

measurements (GET)

Medições de traits (GET lista, POST cria via job de importação, PUT atualiza).

Campos retornados

O perfil simple é a resposta padrão; all acrescenta campos detalhados, técnicos ou de compatibilidade. Use o parâmetro fields para solicitar uma lista explícita.

Exemplo de resposta

{
    "meta": {
        "odb_version": "0.10.0-alpha1",
        "api_version": "v0",
        "server": "http://localhost/opendatabio"
    },
    "data": [
        {
            "id": 853443,
            "basisOfRecord": "MeasurementsOrFact",
            "measured_type": "App\\Models\\Voucher",
            "measured_id": 1519,
            "measurementType": "HasSilica",
            "measurementValue": "Sim",
            "measurementUnit": null,
            "measurementDeterminedDate": "2014-09-24",
            "measurementDeterminedBy": "Equipe FITO",
            "measurementRemarks": null,
            "resourceRelationship": null,
            "resourceRelationshipID": "3304.8846.Equipe-FITO.PDBFF.PDBFF005425",
            "relationshipOfResource": "measurement of",
            "scientificName": "Pouteria fimbriata",
            "family": "Sapotaceae",
            "datasetName": "SILICOTECA",
            "measurementMethod": "Name: Has sílica-gel sample for DNA extraction | Definition:Has a tissue preserved in sílica-gel for DNA extractions. | Categories: CategoryName: Yes | Definition:Has an associated sample in sílica-gel.",
            "sourceCitation": null,
            "measurementLocationId": 29639,
            "measurementParentId": null,
            "decimalLatitude": -2.36495453,
            "decimalLongitude": -59.97365135
        }
    ]
}

media (GET)

Metadados de mídia (GET lista, POST cria, PUT atualiza).

Campos retornados

O perfil simple é a resposta padrão; all acrescenta campos detalhados, técnicos ou de compatibilidade. Use o parâmetro fields para solicitar uma lista explícita.

Exemplo de resposta

{
    "meta": {
        "odb_version": "0.10.0-alpha1",
        "api_version": "v0",
        "server": "http://localhost/opendatabio"
    },
    "data": [
        {
            "id": 20211,
            "model_type": "App\\Models\\Individual",
            "model_id": 111785,
            "basisOfRecord": "MachineObservation",
            "recordedBy": "Francisco Javier Farroñay Pacaya",
            "recordedDate": "2025-03-09",
            "dwcType": "StillImage",
            "resourceRelationship": "Organism",
            "resourceRelationshipID": "3402-1134_Pereira_1986",
            "relationshipOfResource": "StillImage of ",
            "scientificName": "Sacoglottis guianensis",
            "family": "Humiriaceae",
            "datasetName": "Unknown dataset",
            "projectName": "Projeto Dinâmica Biológica de Fragmentos Florestais",
            "taggedWith": "Folha abaxial",
            "accessRights": "Open access.",
            "bibliographicCitation": "Sacoglottis guianensis (Humiriaceae). (2025). By Francisco Javier Farroñay Pacaya. Collection: Pereira, M.J.R. #3402-1134 on 1986-01-24, from Quadrante 52, Parcela 3402-3, Reserva 3402, Cabo Frio, Fazenda Porto Alegre, Amazonas, Brasil (PDBFF). Project: PDBFF-Data. Instituto Nacional de Pesquisas da Amazônia (INPA), Manaus, Amazonas, Brasil. Type: Image. License: CC-BY-NC-SA 4.0. uuid: inpa-odb-3f139ba4-f22b-42d8-9e74-c340309061c2, url: http://localhost/opendatabio",
            "license": "CC-BY-NC-SA 4.0",
            "file_name": "67ce28cd76f4a.jpg",
            "file_url": "http://localhost/opendatabio/storage/media/20211/67ce28cd76f4a.jpg",
            "citation": "Sacoglottis guianensis (Humiriaceae). (2025). By Francisco Javier Farroñay Pacaya. Collection: Pereira, M.J.R. #3402-1134 on 1986-01-24, from Quadrante 52, Parcela 3402-3, Reserva 3402, Cabo Frio, Fazenda Porto Alegre, Amazonas, Brasil (PDBFF). Project: PDBFF-Data. Instituto Nacional de Pesquisas da Amazônia (INPA), Manaus, Amazonas, Brasil. Type: Image. License: CC-BY-NC-SA 4.0. uuid: inpa-odb-3f139ba4-f22b-42d8-9e74-c340309061c2, url: http://localhost/opendatabio",
            "uuid": "3f139ba4-f22b-42d8-9e74-c340309061c2",
            "bibtex": "@misc{Farronay_2025_20211,\n{\n    \"title\": \" Sacoglottis guianensis (Humiriaceae)\",\n    \"year\": \"(2025)\",\n    \"author\": \"Francisco Javier Farroñay Pacaya\",\n    \"howpublished\": \"{http:\\/\\/localhost\\/opendatabio\\/media\\/uuid\\/3f139ba4-f22b-42d8-9e74-c340309061c2}\",\n    \"license\": \"CC-BY-NC-SA 4.0\",\n    \"note\": \"Type: Image; Collection: Pereira, M.J.R. #3402-1134 on 1986-01-24, from Quadrante 52, Parcela 3402-3, Reserva 3402, Cabo Frio, Fazenda Porto Alegre, Amazonas, Brasil (PDBFF); Coordinates: POINT(-59.91500315727877 -2.3929141688648765); License: CC-BY-NC-SA 4.0; Project: PDBFF-Data.; Accessed: 2026-02-04\",\n    \"publisher\": \"Instituto Nacional de Pesquisas da Amazônia (INPA), Manaus, Amazonas, Brasil\"\n}\n}",
            "userName": "example",
            "created_at": "2025-03-09T23:48:29.000000Z"
        }
    ]
}

persons (GET)

Pessoas (GET lista, POST cria, PUT atualiza).

Campos retornados

O perfil simple é a resposta padrão; all acrescenta campos detalhados, técnicos ou de compatibilidade. Use o parâmetro fields para solicitar uma lista explícita.

Exemplo de resposta

{
    "meta": {
        "odb_version": "0.10.0-alpha1",
        "api_version": "v0",
        "server": "http://localhost/opendatabio"
    },
    "data": [
        {
            "id": 3127,
            "full_name": "Raimundo Afeganistão",
            "abbreviation": "AFEGANISTÃO, R.",
            "emailAddress": null,
            "institution": null,
            "notes": "PDBFF"
        },
        {
            "id": 14,
            "full_name": "Maria de Fátima  Agra",
            "abbreviation": "Agra, M.F.",
            "emailAddress": null,
            "institution": null,
            "notes": null
        },
        {
            "id": 15,
            "full_name": "J. L. A. Aguiar Jr",
            "abbreviation": "Aguiar Jr., J.L.A.",
            "emailAddress": null,
            "institution": null,
            "notes": null
        }
    ]
}

projects (GET)

Projetos (GET lista).

Campos retornados

O perfil simple é a resposta padrão; all acrescenta campos detalhados, técnicos ou de compatibilidade. Use o parâmetro fields para solicitar uma lista explícita.

Exemplo de resposta

{
    "meta": {
        "odb_version": "0.10.0-alpha1",
        "api_version": "v0",
        "server": "http://localhost/opendatabio"
    },
    "data": [
        {
            "id": 1,
            "acronym": "PDBFF-Data",
            "name": "Projeto Dinâmica Biológica de Fragmentos Florestais",
            "description": "Este espaço agrega conjuntos de dados de monitoramentos e pesquisas realizadas nas áreas amostrais do PDBFF,  localizadas na Área de Relevante Interesse Ecológico - ARIE PDBFF.",
            "pages": {
                "en": null,
                "pt-br": null
            },
            "urls": [
                {
                    "url": "https://alfa-pdbff.site/",
                    "label": null,
                    "icon": "fa-solid fa-globe"
                }
            ],
            "created_at": "2022-10-31T07:01:18.000000Z",
            "updated_at": "2023-11-17T21:08:55.000000Z"
        }
    ]
}

taxons (GET)

Nomes taxonômicos (GET lista, POST cria).

Campos retornados

O perfil simple é a resposta padrão; all acrescenta campos detalhados, técnicos ou de compatibilidade. Use o parâmetro fields para solicitar uma lista explícita.

Exemplo de resposta

{
    "meta": {
        "odb_version": "0.10.0-alpha1",
        "api_version": "v0",
        "server": "http://localhost/opendatabio"
    },
    "data": [
        {
            "id": 16332,
            "senior_id": null,
            "parent_id": 16331,
            "author_id": null,
            "scientificName": "Aiouea grandifolia",
            "taxonRank": "Species",
            "scientificNameAuthorship": "van der Werff",
            "namePublishedIn": null,
            "parentName": "Aiouea",
            "family": "Lauraceae",
            "higherClassification": "Eukaryota > Plantae > Viridiplantae > Embryophytes > Spermatopsida > Angiosperms > Magnoliidae > Laurales > Lauraceae > Aiouea",
            "taxonRemarks": null,
            "taxonomicStatus": "accepted",
            "acceptedNameUsage": null,
            "acceptedNameUsageID": null,
            "parentNameUsage": "Aiouea",
            "scientificNameID": "https://tropicos.org/Name/17806050 | https://www.gbif.org/species/4175896",
            "basisOfRecord": "Taxon"
        }
    ]
}

traits (GET)

Definições de traits (GET lista, POST cria).

Campos retornados

O perfil simple é a resposta padrão; all acrescenta campos detalhados, técnicos ou de compatibilidade. Use o parâmetro fields para solicitar uma lista explícita.

Exemplo de resposta

{
    "meta": {
        "odb_version": "0.10.0-alpha1",
        "api_version": "v0",
        "server": "http://localhost/opendatabio"
    },
    "data": [
        {
            "id": 206,
            "type": 1,
            "typename": "QUANT_REAL",
            "export_name": "treeDbh",
            "measurementType": "treeDbh",
            "measurementUnit": "cm",
            "range_min": 0.1,
            "range_max": 700,
            "link_type": null,
            "value_length": null,
            "name": "Diâmetro à altura do peito – DAP",
            "description": "Diâmetro à altura do peito, i.e. medido a ca. 1.3m desde a base do caule",
            "objects": "App\\Models\\Individual | App\\Models\\Voucher | App\\Models\\Location | App\\Models\\Taxon | App\\Models\\Media",
            "measurementMethod": "Name: Diameter at breast height - DBH | Definition:Diameter at breast height,, i.e. ca. 1.3 meters from the base of the trunk",
            "MeasurementTypeBibkeys": "",
            "TaggedWith": "",
            "categories": null
        },
        {
            "id": 207,
            "type": 1,
            "typename": "QUANT_REAL",
            "export_name": "treeDbhPom",
            "measurementType": "treeDbhPom",
            "measurementUnit": "m",
            "range_min": 0,
            "range_max": 15,
            "link_type": null,
            "value_length": null,
            "name": "Ponto de medição do DAP",
            "description": "Ponto de medição do DAP, necessário quando impossível medir a 1.3 m",
            "objects": "App\\Models\\Individual",
            "measurementMethod": "Name: DBH Point of Measurement | Definition:DAP measuring height, necessary when impossible to measure at 1.3 m",
            "MeasurementTypeBibkeys": "",
            "TaggedWith": "",
            "categories": null
        },
        {
            "id": 524,
            "type": 2,
            "typename": "CATEGORICAL",
            "export_name": "stemType",
            "measurementType": "stemType",
            "measurementUnit": null,
            "range_min": null,
            "range_max": null,
            "link_type": null,
            "value_length": null,
            "name": "Tipo de fuste",
            "description": "Tipo de fuste",
            "objects": "App\\Models\\Voucher | App\\Models\\Individual | App\\Models\\Taxon",
            "measurementMethod": "Name: Type of stem | Definition:Type of stem | Categories: CategoryName: Main stem | Definition:The main trunk, usually the thickest. | CategoryName: Secondary stem | Definition:A secondary trunk, there is a thicker one, which defines the area better. A shoot below 1.3 m high is a secondary trunk.",
            "MeasurementTypeBibkeys": "",
            "TaggedWith": "",
            "categories": [
                {
                    "id": 12990,
                    "name": "Fuste principal",
                    "description": "O tronco principal, geralmente o mais grosso.",
                    "rank": 1,
                    "belongs_to_trait": "stemType"
                },
                {
                    "id": 12991,
                    "name": "Fuste secundário",
                    "description": "Um tronco secundário, há outro mais grosso, que define melhor a área. Um rebroto abaixo de 1.3 m de altura é um tronco secundário.",
                    "rank": 2,
                    "belongs_to_trait": "stemType"
                }
            ]
        }
    ]
}

vernaculars (GET)

Nomes vernáculos (GET lista, POST cria).

Campos retornados

O perfil simple é a resposta padrão; all acrescenta campos detalhados, técnicos ou de compatibilidade. Use o parâmetro fields para solicitar uma lista explícita.

Exemplo de resposta

{
    "meta": {
        "odb_version": "0.10.0-alpha1",
        "api_version": "v0",
        "server": "http://localhost/opendatabio"
    },
    "data": []
}

vouchers (GET)

Vouchers de coleção (GET lista, POST cria, PUT atualiza).

Campos retornados

O perfil simple é a resposta padrão; all acrescenta campos detalhados, técnicos ou de compatibilidade. Use o parâmetro fields para solicitar uma lista explícita.

Exemplo de resposta

{
    "meta": {
        "odb_version": "0.10.0-alpha1",
        "api_version": "v0",
        "server": "http://localhost/opendatabio"
    },
    "data": [
        {
            "id": 72209,
            "individual_id": 306246,
            "basisOfRecord": "PreservedSpecimens",
            "occurrenceID": "2639.Spruce.K.K000640463",
            "organismID": "2639_Spruce_1852",
            "collectionCode": "K",
            "catalogNumber": "K000640463",
            "typeStatus": "Tipo",
            "recordedByMain": "Spruce, R.",
            "recordNumber": "2639",
            "recordedDate": "1852-10",
            "recordedBy": "Spruce, R.",
            "scientificName": "Ecclinusa lanceolata",
            "scientificNameAuthorship": "(Mart. & Eichler) Pierre",
            "taxonPublishedStatus": "published",
            "genus": "Ecclinusa",
            "family": "Sapotaceae",
            "identificationQualifier": "",
            "identifiedBy": "Spruce, R.",
            "dateIdentified": "1852-10-00",
            "identificationRemarks": "",
            "locationName": "São Gabriel da Cachoeira",
            "higherGeography": "Brasil > Amazonas > São Gabriel da Cachoeira",
            "decimalLatitude": 1.1841927,
            "decimalLongitude": -66.80167715,
            "georeferenceRemarks": "decimal coordinates are the CENTROID of the footprintWKT geometry",
            "occurrenceRemarks": "OrganismRemarks = prope Panure ad Rio Vaupes Amazonas, Brazil",
            "datasetName": "Exsicatas LABOTAM",
            "uuid": "6302316f-2b48-43b5-816b-005df70d15c9"
        }
    ]
}

userjobs (GET)

Jobs em background (importações/exportações) (GET lista).

Campos retornados

O perfil simple é a resposta padrão; all acrescenta campos detalhados, técnicos ou de compatibilidade. Use o parâmetro fields para solicitar uma lista explícita.

Exemplo de resposta

{
    "message": "Unauthenticated",
    "0": 401
}

activities (GET)

Lista entradas do log de atividades.

Campos retornados

O perfil simple é a resposta padrão; all acrescenta campos detalhados, técnicos ou de compatibilidade. Use o parâmetro fields para solicitar uma lista explícita.

Exemplo de resposta

{
    "meta": {
        "odb_version": "0.10.0-alpha1",
        "api_version": "v0",
        "server": "http://localhost/opendatabio"
    },
    "data": [
        {
            "field_key": "taxon_id",
            "field": "Taxon",
            "old_value": "Burseraceae",
            "new_value": "Protium hebetatum forma.b.fito",
            "id": 1411696,
            "log_name": "individual",
            "description": "identification updated",
            "subject_type": "App\\Models\\Individual",
            "subject_id": 301705,
            "subject_name": null,
            "modified_by": "example"
        },
        {
            "field_key": "person_id",
            "field": "Person",
            "old_value": "Macedo, M.T.S",
            "new_value": "Pilco, M.V.",
            "id": 1411696,
            "log_name": "individual",
            "description": "identification updated",
            "subject_type": "App\\Models\\Individual",
            "subject_id": 301705,
            "subject_name": null,
            "modified_by": "example"
        },
        {
            "field_key": "notes",
            "field": "Notes",
            "old_value": "Identificação feita em campo, anotada na planilha de dados.",
            "new_value": null,
            "id": 1411696,
            "log_name": "individual",
            "description": "identification updated",
            "subject_type": "App\\Models\\Individual",
            "subject_id": 301705,
            "subject_name": null,
            "modified_by": "example"
        },
        {
            "field_key": "date",
            "field": "Date",
            "old_value": "2022-06-17",
            "new_value": "2022-11-23",
            "id": 1411696,
            "log_name": "individual",
            "description": "identification updated",
            "subject_type": "App\\Models\\Individual",
            "subject_id": 301705,
            "subject_name": null,
            "modified_by": "example"
        }
    ]
}

tags (GET)

Tags/palavras-chave (GET lista).