This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

Modelo conceitual

Visão geral sobre a estrutura da base de dados e das relações entre modelos!

1 - Objetos Centrais

Objetos que podem receber Medições de Váriaveis dos usuários

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

Esses objetos possuem um ID numérico interno e, quando aplicável, um UUID para links estáveis e intercâmbio de dados. Use o ID numérico em operações que o solicitem explicitamente; use o UUID para citar ou compartilhar um registro sem depender da numeração interna da instalação.

  • O objeto Indivíduo refere-se a um organismo individual que foi observado uma vez (uma ocorrência) ou foi marcado para monitoramento, como uma árvore em uma parcela permanente, uma ave anilhada, um morcego rastreado por rádio. Os indivíduos podem ter um ou mais Vouchers em uma BioColeção e um ou vários Localidades e terão uma Identificação taxonômica. Qualquer atributo medido ou tomado para um individuo pode ser associado a este objeto por meio do modelo Medição.

  • O objeto Vouchers é para registros de espécimes coletados de Indivíduo e depositados em uma BioColeção. A identificação taxonômica e a localização de um voucher é aquela do próprio indivíduo a que pertence. Medições podem ser vinculadas a um Voucher quando você deseja registrar explicitamente os dados para aquela amostra específica (por exemplo, medições morfológicas; um marcador molecular de uma extração de uma amostra em um coleta de tecido). Caso contrário, você pode simplesmente registrar a medição para o indivíduo ao qual o voucher pertence. O modelo de voucher também está disponível como tipo especial de Variável, o LinkType, tornando possível registrar contagens para o táxon do voucher em um determinado local.

  • O objeto Localidades contém geometrias espaciais, como pontos e polígonos, e inclui parcelas e transectos como casos especiais. Um Indivíduo pode ter uma localidade (por exemplo, uma planta) ou multiplas localidades (por exemplo, um animal monitorado). As localidades do tipo PARCELA e TRANSECTO podem ser registradas como geometria espacial ou apenas com geometria de ponto, e podem ter dimensões cartesianas (metros) registradas. Os indivíduos também podem ter posições cartesianas (X e Y ou angle e distance) em relação à sua Localidade, permitindo contabilizar o mapeamento tradicional de indivíduos em unidades de amostragem. Medições ecológicas relevantes, como dados de solo ou clima, são exemplos de Medições que podem ser vinculadas a localidades.

  • O objeto Taxon, além de seu uso para a Identificação taxonômica de Indivíduos, pode receber Medições, permitindo a organização de dados secundários publicados ou qualquer tipo de informação ligada a um nome taxonômico. Uma Referência Bibliográfica pode ser incluída para indicar a fonte de dados. Além disso, o modelo Taxon está disponível como tipo especial de Variável, o LinkType, tornando possível registrar contagens de Taxons em um determinado local.

Localidades

O modelo Localidades armazena dados que representam locais do mundo real. Eles podem ser países, cidades, unidades de conservação ou qualquer polígono espacial, ponto ou trilha na superfície da Terra. Esses objetos são hierárquicos e possuem um relacionamento pai-filho implementado pelo Nested Set Model para dados hierárquicos da biblioteca Laravel Baum que facilita tanto a validação quanto as consultas.

Uma localidade pode representar um ambiente terrestre ou marinho. Usuários plenos podem editar localidades somente enquanto elas não possuem indivíduos, vouchers, medições ou mídias relacionados. Depois que uma localidade passa a ser utilizada, apenas superadministradores podem alterá-la. A exclusão também não é permitida quando existem dados relacionados ou localidades descendentes. Algumas localidades criadas automaticamente pela aplicação são identificadas como localidades do sistema. Para pesquisa e visualização espacial, veja Pesquisar e mapear dados. Para cadastrar países, unidades administrativas, unidades de conservação, parcelas ou transectos sem duplicar a biblioteca compartilhada, consulte Curadoria de Localidades.

Tipos de Localidades especiais são parcelas e transectos, que juntamente com pontos permitem diferentes métodos de amostragem usados ​​em estudos de biodiversidade. Esses tipos de Localidades também podem ser vinculados a uma localidade administrativa pai e, além disso, a três tipos adicionais de localidades pai como Unidades de Conservação, Territórios Indígenas e qualquer camada Ambiental representando classes de vegetação, classes de solo , etc … com geometrias espaciais definidas.

Tabela locations

  • As colunas parent_id junto com rgt, lft e deph são usadas para definir o modelo de conjunto aninhado para consultar ancestrais e descendentes de forma rápida. Apenas parent_id é especificado pelo usuário, as outras colunas são calculadas pela biblioteca Baum a partir dos valores id+parent_id que definem a hierarquia. O mesmo modelo hierárquico é usado para o Taxons, mas para locais há uma restrição espacial, ou seja, um filho deve estar dentro de uma geometria pai.
  • A coluna adm_level indica o nível administrativo, ou tipo, de localidade. Por padrão, os seguintes adm_level são configurados no OpenDataBio:
    • 2 para o país, 3 para a primeira divisão dentro do país (província, estado), 4 para a segunda divisão (por exemplo, município), … até adm_level = 10 como áreas administrativas (o código do país é 2 para permitir a padronização com OpenStreeMaps, que é recomendado seguir se sua instalação incluir dados de diferentes países). Os níveis administrativos podem ser configurados em um OpenDataBio antes de importar quaisquer dados para o banco de dados, consulte o guia de instalação para obter detalhes sobre isso.
    • 99 é o código para Unidades de Conservação - uma unidade de conservação é uma location que pode estar vinculada a vários outros locais (qualquer local pode pertencer a uma única UC). Assim, uma localidade pode ter como pai um município e como uc a unidade de conservação a que pertence.
    • 98 é o código para Territórios Indígenas - mesmas propriedades das Unidades de Conservação, mas tratadas separadamente apenas porque algumas UCs ​​e TIs podem se sobrepor amplamente como é o caso da região amazônica
    • 97 é o código para Camadas ambientais - mesmas propriedades das Unidades de Conservação e Territórios Indígenas, ou seja, podem ser vinculadas como localidade pai adicional a qualquer Ponto, Parcela ou Transecto e, portanto, seus indivíduos relacionados. Armazene polígonos e geometrias de multipolígonos representando classes ambientais, como unidades de vegetação, biomas, classes de solo, etc …
    • 100 é o código para parcelas e sub-parcelas - as localidades de tipo parcelas podem ser registradas com geometria de ponto ou polígono, e também devem ter dimensões cartesianas associadas em metros. Se for uma localização de ponto, a geometria é definida a partir do ponto informado. As dimensões cartesianas de uma localidade de tipo parcela também podem ser combinadas com posições cartesianas de subparcelas (ou seja, uma localidade de parcela cujo pai também é uma localidade de parcela) e/ou de indivíduos dentro de tais parcelas, permitindo que indivíduos e subparcelas sejam mapeados dentro de uma subparcela sem especificações de geometria. Em outras palavras, se a geometria espacial da Parcela for desconhecida, ela pode ter como geometria um único ponto GPS ao invés de um polígono, mais suas dimensões x e y. Uma subparcela é uma parcela cuja localidade pai também é uma parcela, e deve consistir em um ponto marcando o início da subparcela mais suas dimensões cartesianas X e Y. Se a geometria do início da subplot for subparcela, ela pode ser armazenada como uma posição relativa à parcela pai usando startx e starty.
    • 101 para transectos - como parcelas, os transectos podem ser registrados tendo uma geometria LineString ou simplesmente uma única coordenada de Latitude e Longitude e uma dimensão. A dimensão cartesiana x para transectos representa o comprimento em metros e é usada para criar linha (orientada para o Norte) quando apenas um ponto é informado. A dimensão y é usada para validar os indivíduos como pertencentes à uma localidade do tipo transecto e representa a distância máxima da linha que um indivíduo deve cair para ser detectado naquele local.
    • 999 para localidades ‘POINT’ como waypoints GPS - isto é para registro de qualquer ponto no espaço
  • A coluna datum pode registrar a propriedade do datum da geometria, se conhecida. Se deixado em branco, o local é considerado armazenado usando o datum WGS84. Porém, não há conversor embutido de outros tipos de dados. Portanto os mapas exibidos podem ficar incorretos se diferentes projeções forem usadas. Fortemente recomendado projetar dados como WSG84 para padronização.
  • A coluna geom armazena a geometria da localização no banco de dados, permitindo consultas espaciais em linguagem SQL, como detecção das localidades pai. A geometria de um local pode ser POINT, POLYGON, MULTIPOLYGON ou LINESTRING e deve ser formatada usando Well-Known-Text representação geométrica da localidade. Quando um POLYGON é informado, o primeiro ponto dentro da string geométrica é privilegiado, ou seja, pode ser utilizado como referência para marcações relativas. Por exemplo, tal ponto será a referência para as colunas startx e starty de uma subparcela. Portanto, para as geometrias plot e transect, importa qual ponto é listado primeiro na geometria WKT

Acesso a dados usuários completos podem registrar novas Localidades, editar detalhes de Localidades e remover registros de Localidades que não têm dados associados. As Localidades têm acesso público.

Indivíduos

O objeto Indivíduo representa um registro para um organismo individual. Pode ser uma única ocorrência no espaço-tempo de um animal, planta ou fungo, ou um indivíduo monitorado ao longo do tempo, como uma planta em parcela florestal permanente, ou um animal de captura-recaptura ou rádio-rastreamento.

Um Indivíduo pode ter um ou mais Vouchers representando amostras físicas do indivíduo armazenadas em uma ou mais BioColeção e pode ter um ou mais Localidades, representando o local ou locais onde o indivíduo foi registrado.

Indivíduos também podem ter uma Identificação taxonômica, que pode ser própria ou pode depender da identificação de outro indivíduo (identificação-dependente). A identificação é herdada por todos os Vouchers registrados para o Indivíduo. Portanto, os vouchers não têm sua identificação própria. A tabela de Identificações agora referencia sempre individual_id (sem relacionamento polimórfico), e os identificadores são vinculados via pivô identification_person.

Tabela individuals

  • Um registro de um Indivíduo deve especificar pelo menos uma Localidade onde foi registrado, a date do registro, o identificador local tag e o collectors do registro e o dataset ao qual o indivíduo pertence.
  • A localidade pode ser qualquer localidade cadastrada, independente do nível, permitindo armazenar registros históricos cujo georreferenciamento é apenas um local administrativo. Localidades são armazenadas na tabela individual_location, tendo colunas date_time, altitude,notes e relative_position.
  • A coluna relative_position armazena as coordenadas cartesianas do Indivíduo em relação à sua localidade. Isso é apenas para indivíduos localizados em locais do tipo plot, transect ou point. Por exemplo, uma parcela com dimensões de 100x100 metros (1ha) pode ter um indivíduo com posição relativa = PONTO (50 50), que colocará o indivíduo no centro do local (isso é mostrado graficamente na interface da web conforme definido pelas coordenadas x e y do indivíduo). Se a localidade for uma subparcela, a posição dentro da parcela pai também pode ser calculada (isso foi projetado com as parcelas do ForestGeo em mente e é uma coluna na API individual GET. Se a localidade for um PONTO, a posição_relativa pode ser informada como angle (= azimute) e distance, atributos frequentemente medidos em métodos de amostragem. Se a localidade for um TRANSECT, a posição_relativa posiciona o indivíduo em relação à linha, sendo x a distância ao longo do transecto a partir do primeiro ponto, e o y a distância perpendicular onde o indivíduo está localizado, também levando em consideração alguns métodos de amostragem;
  • O campo date nos modelos Indivíduo, Voucher, Medição e Identificação pode ser uma Data Incompleta, ou seja, apenas o ano ou ano + mês podem ser registrados.
  • A tabela Collector representa os coletores para um indivíduo ou voucher e está vinculada ao Modelo de pessoa. A tabela de coletores possui uma relação polimórfica com os objetos Voucher e Individual, definidos pelas colunas object_id e object_type, permitindo múltiplos coletores para cada registro individual ou voucher. O main_collector indicado é apenas o primeiro coletor listado para essas entidades.
  • O campo tag é um código identificador para o indivíduo. Pode ser o número escrito na etiqueta de alumínio de uma árvore em uma parcela florestal, o número de uma anilha numa ave, ou o número de coletor de um espécime. A combinação de main_collector + tag + first_location é restrita a ser única no OpenDataBio. A identificação taxonômica de um indivíduo pode ser definida de duas maneiras:
    • para identificação-própria um registro de Identificação taxonômica é criado na tabela de identifications e a coluna identification_individual_id é preenchida com o próprio id do indivíduo
    • para identificação-dependente, o id do Indivíduo que possui a Identificação é armazenado na coluna identification_individual_id.
    • Conseqüentemente, o modelo Indivíduo contém dois métodos para se relacionar com o modelo de Identificação: um que define identificação-própria e outro que recupera as identificações taxonômicas usando a coluna identification_individual_id.
  • Os indivíduos podem ter um ou mais Vouchers depositados em uma BioColeção.

    Acesso a dados Indivíduos pertencem a conjuntos de dados, então a política de acesso do conjuntos de dados se aplica aos indivíduos nele inseridos. Apenas os colaboradores e administradores do Conjunto de Dados podem inserir ou editar indivíduos, mesmo se o conjunto de dados for de acesso público.

Taxons

O modelo Taxon organiza nomes publicados e não publicados em uma hierarquia. Nomes publicados podem ser consultados em serviços nomenclaturais externos; nomes não publicados, como morfotipos, são definidos localmente e precisam de uma Pessoa como autor. Sinônimos são mantidos como Taxons próprios e vinculados ao nome aceito. O nível clado permite representar nós que não correspondem às categorias taxonômicas tradicionais.

A interface permite navegar pela árvore taxonômica sob demanda, expandindo os descendentes sem carregar todo o backbone de uma vez. Em pesquisas, diferencie uma correspondência exata, que usa apenas o Taxon selecionado, de uma busca pela raiz taxonômica, que inclui seus descendentes. Essa escolha altera substancialmente resultados de listas, datasets, mapas e exportações.

Fluxo para cadastrar um nome publicado

  1. Pesquise o nome no OpenDataBio para evitar duplicar um Taxon existente.
  2. Informe o nome científico completo e execute a verificação externa.
  3. O sistema consulta primeiro o GBIF. Para nomes reconhecidos como fungos, consulta o Index Fungorum e o utiliza como fonte nomenclatural principal, complementando o resultado com a chave do GBIF quando possível.
  4. Para plantas, o resultado pode ser complementado por Tropicos e IPNI, especialmente para autoria, publicação e chaves externas.
  5. Se o GBIF não encontrar o nome, o sistema também tenta o Index Fungorum e, depois, Tropicos e IPNI. Outros identificadores externos, como MycoBank e ZooBank, podem ser preservados quando retornados pelas fontes integradas.
  6. Revise nome, autoria, rank, nome aceito, pai, referência de publicação e chaves externas antes de salvar.
  7. Se as fontes discordarem sobre o conceito, autoria, pai ou nome aceito, o sistema não deve decidir silenciosamente: compare as fontes e resolva o conflito manualmente.

As fontes têm coberturas diferentes. Index Fungorum é a referência preferencial no fluxo de fungos; Tropicos e IPNI são particularmente úteis para plantas; GBIF oferece cobertura taxonômica ampla. Uma chave externa documenta a correspondência com a fonte, mas não transfere para ela a decisão curatorial do OpenDataBio.

Revalidar Taxons existentes

A ferramenta de validação externa permite revisar Taxons publicados por projeto, dataset ou raiz taxonômica. Ela separa atualizações aplicáveis, conflitos, nomes aceitos ou pais ausentes e decisões manuais. Usuários plenos podem executar verificações e aplicar mudanças quando possuem permissão sobre o Taxon; nos demais casos, podem registrar sugestões. Alterações amplas e operações administrativas devem ser revisadas por superadministradores.

Veja o fluxo completo em Curadoria de bibliotecas compartilhadas.

Se nenhuma fonte resolver um nome que você sabe ser publicado, confira a grafia, autoria e categoria. O formulário permite confirmar manualmente um nome publicado não resolvido. Não marque como não publicado apenas porque um serviço está indisponível.

Fluxo para nomes não publicados

Marque o Taxon como não publicado, selecione uma Pessoa como autor, defina o rank e escolha o pai apropriado. Não use a consulta externa para transformar um morfotipo ou nome provisório em um nome publicado. Se esse nome for publicado posteriormente, revise o registro e suas relações com cuidado em vez de criar uma duplicata automaticamente.

Tabela Taxon

  • Como, Localidades, o modelo Taxon tem um relacionamento pai-filho, implementado usando o modelo de conjunto aninhado para dados hierárquicos da biblioteca Laravel Baum que permite consultar ancestrais e descendentes. Consequentemente, as colunas rgt, lft e deph da tabela de taxons são preenchidas automaticamente por esta biblioteca na inserção ou atualização dos dados.
  • Para ambos, Taxon author e Taxon bibreference, existem duas opções:
    • Para nomes publicados, a autoria da string recuperada pelas APIs será colocada na coluna author = string. Para nomes não publicados, o autor é uma pessoa e será armazenado na coluna author_id.
    • Somente nomes publicados podem ter relação com BibReferences. O campo de string bibreference da tabela Taxon armazena as strings recuperadas por meio de APIs externas, enquanto o bibreference_id se vincula a um objeto Referência Bibliográfica. Eles são usados ​​para armazenar a publicação onde o nome do táxon é descrito e pode ser inserido em ambos os formatos.
    • Além disso, um registro de táxon também pode ter muitas outras referências de Bib por meio de uma tabela dinâmica (taxons_bibreference), permitindo vincular qualquer número de referências bibliográficas a um nome de táxon.
  • A coluna level representa a classificação taxonômica (como ordem, gênero, etc.). Ele é numericamente codificado e padronizado de acordo com as regras gerais do IAPT, mas deve acomodar também categorias de nível de táxon relacionadas a animais. Consulte os códigos disponíveis na API Taxon para obter a lista de códigos.
  • A coluna parent_id indica o pai do táxon, que pode estar vários níveis acima dele. O nível dos pais deve ser estritamente mais alto do que o nível do táxon, mas você não precisa seguir a hierarquia completa. É possível registrar um táxon sem os pais, por exemplo, um morfotipo não publicado para o qual o gênero e a família são desconhecidos pode ter uma ordem como pai.
  • Os nomes das classificações taxonômicas são traduzidos de acordo com o locale definido pelo sistema, que também traduz a interface da web (atualmente implementados apenas em português e inglês).
  • O campo nome da tabela de táxons contém apenas a parte específica do nome (no caso de espécies, o epíteto específico), mas a inserção e exibição dos táxons por meio da API ou interface web deve ser feito com a combinação fullname.
  • É possível incluir sinônimos na tabela Taxon. Para isso, deve-se preencher o relacionamento senior, que é o id do nome aceito (valid) para um táxon invalid. Se senior_id for preenchido, o táxon é um sinônimo junior e deve ser marcado como invalid.
  • Taxons podem manter chaves de GBIF, Index Fungorum, Tropicos, IPNI, MycoBank e ZooBank. Essas chaves criam links verificáveis para os registros externos e ajudam futuras revisões.
  • Pessoas pode ser definidas como especialistas em táxons por meio de uma tabela dinâmica. Assim, um objeto Taxon pode ter vários especialistas taxonômicos registrados no OpenDataBio.



Acesso a dados: usuários plenos podem registrar um novo táxon e editar os registros existentes se eles não tiverem sido usados ​​para identificação. Atualmente é impossível remover um táxon do banco de dados. A lista de táxons tem acesso público.

Vouchers

O modelo Voucher é usado para armazenar registros de espécimes ou amostras de indivíduos depositados em BioColeções. Portanto, as únicas informações obrigatórias exigidas para registrar um Voucher são individual, biocollection e se o espécime é um tipo de nomenclatural (o padrão é non-type se não informado).

Vouchers table explained

  • O Voucher pertence a um Indivíduo e a uma Biocoleção, portanto o individual_id e o biocollection_id são obrigatórios nesta tabela;
  • biocollection_number é o código alfanumérico do Voucher na Biocoleção, pode ser ’nulo’ para usuários que desejam apenas indicar que um Indivíduo registrado tem Vouchers em uma Bicoleção específica, ou para Vouchers registrados para biocoleções que não tem um código identificador;
  • biocollection_type - é um código numérico que especifica se o Voucher na BioCollection é um tipo nomenclatural. O padrão é 0 (não é um tipo); 1 apenas para ‘Tipo’, uma forma genérica e outros números para outros tipos nomenclaturis
  • collectors, um ou múltiplos, são opcionais para Vouchers, exigidos apenas se forem diferentes dos Coletores do Indivíduo. Caso contrário, os coletores do Indivíduo são herdados pelo Voucher. Como para indivíduos, eles são implementados por meio de uma relações polimórfica com a tabela de collectors e o primeiro coletor é o coletor_principal para o voucher, ou seja, aquele que se relaciona com number.
  • number, este é o número do coletor, mas como coletores, só deve ser preenchido se for diferente do valor da tag do indivíduo. Portanto, collectors, number e date são úteis para registrar Vouchers para Indivíduos que têm Vouchers coletados em momentos diferentes por pessoas diferentes.
  • O campo date nos modelos indivíduos e Voucher pode ser uma data incompleta. Exigido apenas se for diferente do indivíduo a quem o voucher pertence.
  • dataset_id o Voucher pertence a um Dataset, que controla a política de acesso;
  • notes qualquer anotação de texto para o Voucher.
  • O modelo de Voucher interage com o modelo BibReference, permitindo vincular citações múltiplas a Vouchers. Isso é feito através da table voucher_bibreference.



Acesso a dados Os vouchers pertencem a Conjuntos de Dados, portanto, a política de acesso a conjuntos de dados se aplica aos vouchers nele contidos. Os vouchers podem ter um conjunto de dados diferente de seus indivíduos. Se a política do conjunto de dados do Voucher for de acesso aberto e a Indivíduo não, o acesso aos dados do voucher será incompleto, portanto, o conjunto de dados do Voucher deve ter a mesma política de acesso ou uma política de acesso menos restrito do que o conjunto de dados do Indivíduo. Apenas os colaboradores e administradores do conjunto de dados podem inserir ou editar vouchers em um conjunto de dados, mesmo se o conjunto de dados for de acesso público.

Arquivos de Mídia

Arquivos de mídia (imagens, vídeos, áudios) são objetos centrais e podem receber Medições, além de descrições, tags e links para Localidades, Indivíduos, Vouchers ou Taxons.

  • Relacionamento principal: polimórfico (model_type, model_id) para Individual, Voucher, Localidade, Táxon ou Projeto.
  • dataset_id opcional: quando presente, a licença e o acesso herdam do Dataset; quando ausente, a mídia pode usar apenas project_id ou ficar solta (ainda com controles básicos).
  • project_id opcional: útil para agrupar e controlar acesso de mídia mesmo sem dataset.
  • Coletores: créditos via tabela polimórfica collectors (múltiplas Pessoas).
  • Tags: muitas-para-muitas com Tags, facilitando filtros.
  • Custom properties (Spatie Media Library): license (fallback se não houver dataset), date (usada em citações), notes, user_id, voucher_id e location_id auxiliares, citation_fields (define o que entra na citação), além de uuid e URLs gerados pela biblioteca.
  • Citações: geradas automaticamente a partir de autores, táxon, dataset/projeto, localização, licença e uuid; BibTeX disponível (generate_citation).
  • Armazenamento: usa o pacote spatie/laravel-medialibrary; arquivos ficam no disco configurado e metadados na tabela media.
  • Upload: interface web aceita lote (zip + csv) e metadados; API media segue a mesma lógica.
  • Medições: aceitam medições via relação polimórfica.

Acesso a dados: se houver dataset_id, a política/licença seguem o Dataset; caso contrário, valem as permissões do Projeto ou as regras gerais de mídia. Usuários completos podem registrar mídia; administradores do dataset (quando existir) também podem excluí-la.

2 - Objetos de Atributos

Objetos para variáveis ​​definidas pelo usuário e suas medições

Medições

A tabela measurements armazena os valores para variáveis medidas para os objetos centrais, incluindo Arquivos de Mídia. Seu relacionamento com os objetos centrais é definido por uma relações polimórficas usando as colunas measured_id e measured_type.

  • medições devem pertencer a um Conjuntos de dados - coluna dataset_id, que controla a política de acesso
  • Uma Pessoa deve ser indicada como o medidor (person_id);
  • A coluna bibreference_id pode ser usada para vincular medições extraídas de publicações à sua fonte fonte Bibliográfica
  • O valor para a variável medida (trait_id) será armazenado em colunas diferentes, dependendo do tipo de variável:
    • value - esta coluna flutuante armazenará valores para características reais quantitativas;
    • value_i - esta coluna inteira armazenará valores para características Quantitative Integer; e é um campo opcional para características do tipo Link, permitindo, por exemplo, armazenar contagens para uma espécie (uma característica Link Taxon) em um local.
    • value_a - esta coluna de texto armazenará valores para os tipos de traço Texto, Cor e Espectral.
  • Valores para variáveis categóricas e ordinais são armazenados na tabela measurement_category
  • data - a data de medição é obrigatória em todos os casos

Acesso a dados As medições pertencem a Conjuntos de dados, portanto, a política de acesso a conjuntos de dados se aplica às medições nele. Apenas os colaboradores e administradores do conjunto de dados podem inserir ou editar medições em um conjunto de dados, mesmo se o conjunto de dados for de acesso público.

Variáveis

A tabela traits representa as variáveis ​​definidas pelo usuário para coletar Mediçõespara um dos objetos centrais.

Essas características personalizadas fornecem enorme flexibilidade aos usuários para registrar suas variáveis ​​de interesse. Obviamente, tal flexibilidade tem um custo na padronização dos dados, pois uma mesma variável pode ser registrada de forma diferentes em qualquer instalação do OpenDataBio. Para minimizar a redundância na ontologia de características, os usuários que criam características são avisados ​​sobre esse problema e uma lista de características semelhantes é apresentada no caso de ser encontrada por comparação de nomes de características.

As variáveis têm restrições de edição para evitar perda de dados ou alteração não intencional do significado dos dados. Portanto, embora a lista de variáveis esteja disponível para todos os usuários, as definições de variáveis não podem ser alteradas se outra pessoa também usou a variável para armazenar medições.

Variáveis são entidades traduzíveis, então seus valores de name e description podem ser armazenados em vários idiomas (veja traduções de usuário. Isso é colocado na tabela user_translations através de uma relação polimórfica.

A definição da variável deve ser tão específica quanto necessário. A medição da altura das árvores usando medição direta ou um clinômetro, por exemplo, pode não ser facilmente convertida de uma para outra e deve ser armazenada em variáveis diferentes. Portanto, é altamente recomendável que o campo de definição de variável inclua informações como instrumento de medição e outros metadados que permitam que outros usuários entendam se podem usar sua variável ou criar uma nova.

  • A definição da variável deve incluir um export_name, que será usado durante as exportações de dados nos formulários de entrada da interface. Os nomes de exportação devem ser únicos e não devem ter tradução. São recomendados nomes de exportação curtos e [camelCase]​​(https://en.wikipedia.org/wiki/Camel_case) ou [PascalCase]​​(https://en.wikipedia.org/wiki/pascal_case).
  • Os seguintes tipos de características estão disponíveis:
    • Quantitativo real - para números reais;
    • Número inteiro quantitativo - para contagens;
    • Categórico - para varáveis categóricas de seleção única;
    • Múltiplo categórico - para muitas categorias selecionáveis;
    • Ordinal categórico - para uma categoria ordenada selecionável (dados semiquantitativos);
    • Texto - para qualquer valor de texto;
    • Cor - para qualquer valor de cor, especificado pelo código de cor hexadecimal (paleta de cores)
    • Link - este é um tipo de variável especial no OpenDataBio. Apenas links para Taxons e Vouchers estão implementados. Exemplo de uso: se você deseja armazenar contagens de espécies conduzidas em uma Localidade, você pode criar uma variável do tipo de link_taxon ou link_voucher. A medição para tal variável terá um campo opcional value para armazenar as contagens. Este tipo de característica também pode ser usado para especificar o hospedeiro de um parasita ou o número de insetos predadores.
    • Espectral - projetado para acomodar dados espectrais, compostos de vários valores de absorbância ou refletância para diferentes números de onda.
    • GenBank - armazena os números de acesso do GenBank que permitem recuperar dados moleculares vinculados a indivíduos ou vouchers armazenados no banco de dados através do GenBank Serviço API.
  • A tabela Traits contém campos que permitem a validação do valor da medição, dependendo do tipo de variável:
    • range_max e range_min - se definido para variáveis quantitativas, as medições terão que se ajustar ao intervalo especificado;
    • value_length - obrigatório apenas para variáveis espectrais, valida o comprimento (número de valores) de uma medição espectral;
    • link_type - se a variável for do tipo Link, a medição em value_i deve ser um id do objeto do tipo de link;
    • Para variáveis do tipo cor, os valores são validados no processo de criação da medição e devem estar em conformidade com um código hexadecimal de cores. Um seletor de cores é apresentado na interface web para inserção e edição de medições de cores;
    • Variáveis categóricas e ordinais serão validadas para as categorias registradas ao importar medições por meio da API;
  • A coluna unit define a unidade de medida para a variável.
  • A coluna bibreference_id é a chave de uma única Referência Bibliográfica que pode ser vinculad à definição da variável.
  • A tabela trait_objects armazena o tipo de objetos centrais para o qual a variável pode ter uma medição;

Acesso aos dados O nome, definição, unidade e categorias de uma variável não podem ser atualizados ou removidos se houver alguma medição registrada no banco de dados. As únicas exceções são: (a) é permitido adicionar novas categorias para variáveis categóricas (não ordinais); (b) o usuário atualizando a variavel é a única pessoa que possui medições para a característica; (c) o usuário que atualiza a variável é um administrador de todos os conjuntos de dados com medições usando a variável.

Unidades de Traits

Unidades são uma biblioteca reutilizável. Pesquise símbolo, nome e significado antes de criar uma nova unidade e não crie outra apenas para mudar maiúsculas, plural ou idioma. A definição de um Trait deve deixar claro como o valor foi medido, porque duas variáveis expressas na mesma unidade não são necessariamente equivalentes.

Usuários plenos podem criar unidades. Uma unidade sem Traits associados, ou associada apenas a Traits ainda sem medições, pode ser corrigida por usuários plenos. Quando já existem medições, a alteração exige que o usuário administre todos os datasets que usam os Traits associados; superadministradores podem intervir globalmente. A exclusão só é permitida quando nenhum Trait usa a unidade.

Formulários (web e coleta móvel)

Formulários definem quais informações serão coletadas, para quais objetos e por quais usuários. Eles não criam um novo tipo de dado: organizam a entrada de Traits, medições e outros campos já definidos pelo OpenDataBio.

Formulários web

Um formulário web reúne Traits para registrar várias medições de um objeto na mesma sessão. Uma Tarefa de Formulário aplica esse protocolo a uma lista de objetos-alvo e pode distribuir o preenchimento entre usuários autorizados. Use uma tarefa quando for importante acompanhar quais objetos ainda não foram medidos.

OpenDataBio Collect

Formulários móveis definem o protocolo usado pelo aplicativo Android OpenDataBio Collect. Eles podem incluir bibliotecas de Taxons e objetos-alvo, geolocalização, fotografias e campos de medição. O usuário baixa a definição e as bibliotecas, coleta offline e sincroniza os registros quando houver conexão.

Fluxo recomendado

  1. defina o dataset de destino e confirme quem pode inserir dados nele;
  2. cadastre ou revise Traits, unidades e categorias antes de criar o formulário;
  3. escolha o tipo de objeto medido e os campos obrigatórios;
  4. atribua somente os usuários que executarão a coleta;
  5. para ODBCollect, prepare a definição e aguarde o UserJob que gera as bibliotecas necessárias;
  6. teste o formulário com poucos objetos e sincronize os resultados;
  7. confira medições, coordenadas, mídias, identificações e avisos do UserJob;
  8. só então distribua o formulário para a coleta completa.

Um usuário pleno pode criar formulários quando possui ao menos um dataset editável. Fora os superadministradores, somente o proprietário pode editar o formulário. Usuários designados para coleta podem consultar sua definição. A exclusão depende também das tarefas e atribuições existentes; não exclua um formulário usado em uma coleta sem revisar essas relações.

3 - Objetos de Acesso

Objetos que controlam o acesso e distribuição de dados!

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

Conjuntos de dados agrupam registros, definem a política de acesso e fornecem versões de publicação explícitas e citáveis. Eles podem conter Medições, Indivíduos, Vouchers e Arquivos de Mídia.

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

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

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

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

BioColeções

BioColeções identificam onde Vouchers estão depositados. Elas podem representar herbários, museus, coleções de tecidos e outras coleções formais ou informais.

Fluxo de cadastro e Index Herbariorum

  1. Pesquise a sigla para evitar duplicar uma coleção existente.
  2. Para um herbário registrado no Index Herbariorum, informe a sigla oficial e use a ação de consulta. O OpenDataBio recupera o identificador irn e o nome mantido pelo Index Herbariorum.
  3. Confira se a instituição retornada corresponde ao herbário desejado. A sigla pode ter mudado ou a consulta pode estar temporariamente indisponível.
  4. Para coleções que não pertencem ao Index Herbariorum, informe sigla e nome manualmente. Não use uma correspondência aproximada de herbário para uma coleção zoológica, de tecidos ou outra coleção distinta.
  5. Salve a BioColeção antes de registrar Vouchers nela.

O Index Herbariorum é usado apenas para identificar herbários; ele não valida Taxons. Para fungos, o serviço nomenclatural usado no fluxo taxonômico é o Index Fungorum.

Uma BioColeção também pode ser administrada pelo sistema. Nesse caso, sua equipe controla a edição dos Vouchers nela depositados e dos respectivos Indivíduos. Ela também trata solicitações para registrar Vouchers de material que um usuário deseja depositar e para emprestar material já depositado. Medições e Mídias continuam sob as permissões de seus próprios datasets. Veja o fluxo completo em Fluxos de coleção. Somente um superadministrador pode habilitar esse modo e deve definir pelo menos um administrador da coleção.

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

Acesso a dados - Usuários plenos podem registrar BioColeções, mas apenas superadministradores podem tornar uma BioColeção administrável pelo sistema. Uma BioColeção só pode ser removida quando não possui Vouchers vinculados e não é administrada pelo sistema. Na coleção gerenciada, administradores gerenciam a equipe e as operações administrativas; colaboradores podem tratar solicitações e editar os registros, mas não apagá-los. Registros pertencentes a diferentes datasets podem integrar a mesma coleção: os datasets continuam definindo visibilidade e autoria, enquanto a BioColeção controla a edição dos Vouchers e Indivíduos sob sua responsabilidade.

Conjuntos de Dados

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

Administradores podem definir o nível de acesso para:

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

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

Versões de conjuntos de dados

Um conjunto de dados é gerenciado continuamente; uma versão é um snapshot fixo preparado para distribuição. Cada versão recebe um UUID e preserva seu escopo, data, autores, licença, política, citação, metadados e arquivos. Filtros podem limitar a versão a uma parte documentada do dataset.

O arquivo principal inclui os dados, um README e a descrição dos campos; um arquivo de mídias separado pode estar disponível. Downloads podem exigir a aceitação de um acordo e são registrados para que os administradores do dataset acompanhem seu uso.

Use o UUID da versão para citar conteúdo fixo. Use a página do dataset para o conjunto gerenciado que continua evoluindo. O fluxo completo está em Organizar e publicar datasets.

Projetos

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

Usuários

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

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

Cada usuário recebe o nível usuário registrado ao se autocadastrar. Um superadministrador pode promovê-lo a Usuário Pleno ou SuperAdmin. Também pode autorizar um usuário pleno a gerenciar acessos. Esse gestor delegado pode promover usuários registrados a usuários plenos e rebaixá-los novamente, mas não pode alterar superadministradores, outros gestores de acesso nem delegar sua própria permissão. Somente superadministradores podem excluir contas.

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

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

UserJobs

O modelo UserJob registra tarefas em segundo plano, como importações, exportações e operações de manutenção, independentemente da linha interna da fila do Laravel. Ele armazena progresso e logs e pode guardar resultados estruturados e ordenados para cada registro processado. Os resultados distinguem sucessos, avisos e erros e podem informar o identificador do objeto afetado. Assim, uma tarefa concluída ainda pode conter avisos ou falhas em algumas linhas.

Usuários podem inspecionar suas tarefas e resultados, baixar identificadores afetados, cancelar tarefas em execução e retomar operações que ofereçam suporte explícito à retomada. Excluir um UserJob remove o histórico da tarefa; isso não substitui o cancelamento de um processo que ainda está em execução.

4 - Objetos Auxiliares

Bibliotecas de uso comum, como Pessoas, Referências Bibliográficas, BioColeção e Traduções de Usuário!

Referências Bibliográficas

Referências são armazenadas em formato BibTeX e podem ser vinculadas a datasets, Taxons, medições, traits, identificações e outros objetos que precisam documentar uma fonte.

Fluxo de cadastro

  1. Pesquise pelo título, autor, chave BibTeX ou DOI para evitar duplicatas.
  2. Se a publicação possui DOI, informe-o e solicite a busca externa. O sistema tenta recuperar um registro BibTeX por meio dos resolvedores de DOI.
  3. Revise o BibTeX recuperado, principalmente autores, título, ano, tipo da publicação, DOI e chave.
  4. Se a busca não encontrar a publicação, cole um registro BibTeX exportado por seu gerenciador bibliográfico ou importe um arquivo .bib.
  5. Salve e só então vincule a referência aos objetos correspondentes.

A consulta por DOI é uma ajuda de preenchimento, não uma validação editorial. O usuário deve conferir o resultado. DOI repetido e chave BibTeX repetida são tratados como possíveis registros já existentes; não altere a chave apenas para contornar uma duplicata sem antes comparar as referências.

Essas referências podem ser usadas para:

  • Conjuntos de dados - com a opção de definir referências para as quais a citação é obrigatória quando o Conjunto de Dados for usado em publicações; mas todas as referências que usaram o conjunto de dados podem ser vinculadas ao conjunto de dados; os links são feitos com uma tabela dinâmica chamada dataset_bibreference;
  • Taxons:
    • para especificar a referência na qual o nome do táxon foi descrito, atualmente obrigatório em algumas revistas taxonômicas como PhytoTaxa. Esta referência de descrição é armazenada no bibreference_id da tabela Taxons.
    • para registrar qualquer referência a um nome de táxon, que são então vinculados por meio de uma tabela dinâmica chamada taxons_bibreference.
  • Vincule uma Medição a uma fonte publicada;
  • Indique a origem de uma definição de Variável.
  • Indique citações obrigatórias para um conjunto de dados ou vincule referências usando os dados para um conjunto de dados

Autores, título, ano, DOI e chave são extraídos do BibTeX. A chave deve ser única; o formulário pode padronizá-la a partir do primeiro autor, ano e título.

Acesso a dados usuários plenos podem registrar novas referências, editar detalhes de referências e remover registros de referência que não têm dados associados. BibReferences tem acesso público!

Identificação Taxonômica

O modelo Identificação representa a identificação taxonômica de Indivíduos.

Tabela identifications

  • O modelo de Identificação inclui vários campos opcionais, mas além de taxon_id, os identificadores (ligados via pivô identification_person) e a date de identificação são obrigatórios.
  • O valor de date pode ser uma Data Incompleta, por exemplo apenas o ano ou ano + mês podem ser registrados.
  • Os seguintes campos são opcionais:
    • modifier - é um código numérico que anexa um modificador taxonômico ao nome. Valores possíveis ’s.s.’ = 1, ’s.l.’ = 2, ‘cf.’ = 3, ‘aff.’ = 4, ‘vel aff.’ = 5, o padrão é 0 (nenhum).
    • notes - um texto de escolha, útil para adicionar comentários à identificação.
    • biocollection_id e biocollection_reference - esses campos devem ser usados ​​para indicar que a identificação é baseada na comparação com um voucher depositado em uma coleção biológica e cria um link entre o indivíduo identificado e o espécime da BioColeção no qual a identificação foi baseada. biocollection_id armazena o id de BioColeção e biocollection_reference o identificador único do espécime comparado, ou seja, seria o equivalente ao biocollection_number do modelo Voucher, mas esta referência não precisa ser de um voucher registrado no banco de dados.
  • Cada identificação referencia diretamente individual_id; não há mais relacionamentos polimórficos para identificações.
  • Mudanças na identificação atual podem gerar registros no Histórico de Identificações, preservando a interpretação biológica anterior, as pessoas, a data, as referências e as evidências correspondentes.

O Histórico de Identificações e o log de atividades têm finalidades diferentes. O primeiro representa a sequência científica de determinações taxonômicas de um indivíduo. O segundo é uma trilha de auditoria das alterações feitas no sistema. Novas importações de história biológica devem usar o endpoint identification-histories, não atividades.

Acesso aos dados: as identificações são atributos dos Indivíduos e não possuem acesso independente!

Pessoas

O modelo Persons armazena nomes de pessoas que podem ou não ser um Usuário diretamente envolvido com a base de dados. Pessoas podem ser: * coletores de Vouchers, Indivíduos e Arquivos de Mídia * identificadores taxonômicos de Indivíduos; * medidores de Medições; * autores para nomes não publicados de Taxons; * especialistas taxonômicos - ligados ao modelo Taxon pela tabela person_taxon; * autores de Conjuntos de Dados

Antes de criar uma Pessoa, pesquise nome, abreviatura, instituição e ORCID. Uma Pessoa é uma identidade compartilhada para autoria, coleta, medição e identificação; não é apenas um contato dentro de um projeto. Usuários plenos podem editar sua própria Pessoa padrão e registros ainda não utilizados. Uma Pessoa usada como padrão por outro usuário ou já relacionada a dados possui restrições de edição e exclusão.

A união de Pessoas duplicadas é uma operação exclusiva de superadministradores, pois substitui relações em várias partes do sistema. Veja Curadoria de bibliotecas compartilhadas.

Tabela persons

  • as colunas obrigatórias são a pessoa full_name e abbreviation;
  • ao cadastrar uma nova pessoa, o sistema sugere o nome abbreviation, mas o usuário é livre para alterá-lo para melhor adaptá-lo à abreviatura usual de cada pessoa. A ** abreviatura deve ser única ** no banco de dados, duplicatas não são permitidas na tabela Pessoas. Portanto, duas pessoas com exatamente o mesmo nome devem ser diferenciadas de alguma forma na coluna abbreviation.
  • A coluna biocollection_id da tabela Pessoas é usada para listar a qual BioColeção uma pessoa está associada, que pode ser usada quando a Pessoa também é um especialista taxonômico.
  • Adicionalmente, também podem ser informados o e-mail e a institution a que pertence a pessoa.
  • Cada usuário pode ser vinculado a uma pessoa pelo person_id na tabela Usuário. Essa pessoa é então usada como a pessoa ‘padrão’ quando o usuário está logado no sistema.

Acesso a dados usuários plenos podem registrar novas pessoas e editar as pessoas inseridas e remover pessoas que não possuem dados associados. Os administradores podem editar qualquer pessoa. A lista de pessoas tem acesso público.

Tag Model

O modelo Tag permite que os usuários definam palavras-chave traduzíveis que podem ser usadas para sinalizar Conjuntos de dados, Projetos ou Arquivos de Mídia. O modelo Tag está vinculado a esses objetos por meio de uma tabela para cada um, denominada dataset_tag, project_tag e media_tag, respectivamente.

Um Tag pode ter name e description em cada idioma configurado na tabela de Idiomas, que serão armazenados na tabela user_translations. As entradas para cada idioma são mostradas nos formulários da interface.

Acesso a dados usuários plenos podem registrar tags, editar as inseridas e excluir as que não foram usadas. As tags têm acesso público, pois são apenas palavras-chave para facilitar a navegação.

Jobs do usuário

UserJobs representam importações, exportações e outras operações executadas em segundo plano. Cada tarefa apresenta estado, progresso e logs e pode guardar resultados estruturados para cada registro processado, distinguindo sucesso, aviso e erro. Portanto, uma tarefa concluída ainda pode conter linhas que precisam de revisão.

O usuário pode acompanhar suas tarefas, examinar resultados, baixar identificadores afetados e, quando a operação permitir, cancelar ou retomar o processamento. Excluir o registro de um UserJob não substitui o cancelamento de uma tarefa ainda em execução.

Administradores da instalação devem manter os workers da fila e definir uma política para retenção de logs e arquivos. Usuários são responsáveis por revisar os resultados de suas próprias operações.

Traduções do usuário

O modelo UserTranslation armazena as traduções de dados do usuário para: descrições e nomes de Variáveis e de categorias para variáveis categóricas; descrições de Arquivos de Mídia e para Tags. As relações com esses modelos são estabelecidas por relações polimórfica usando os campos translatable_type e translatable_id. Este modelo permite traduções para qualquer idioma listado na tabela languages, atualmente acessível apenas para inserção e edição diretamente no banco de dados SQL. Os formulários de entrada na interface web serão listados para os idiomas registrados.

Vernacular - Nome Popular

Os modelos Vernacular e VernacularCitation permitem registrar nomes populares de organismos, relacionando-os à Taxons e/ou Individuals, ou de paisagens e tipos de ambiente e vegetação, relacionando-os à Locations. A combinação nome+idioma deve ser única na tabela vernaculars e cada registro pode ser vinculado a múltiplos Táxons e/ou Indivíduos, ou Localidades, dependendo das fontes de informação. Cada registro também pode ter uma ou mais citações (texto de citação + BibReference + nota).

  • Suporta múltiplos idiomas para o nome popular; o idioma é obrigatório em cada registro e a interface já tem cadastrada uma lista ampla de valores possíveis em config/languagesISO6393.php
  • VernacularCitations permite adicionar várias citações sobre os nomes populares.
  • Formulários ODBCollect podem exigir nomes populares, permitindo capturar o vernacular no campo junto com medições, táxon e/ou indivíduo, e/ou com uma localidade.

O idioma é parte do significado do registro. Antes de criar um nome, procure a mesma grafia e confira suas relações e citações. Em muitos casos, o correto é acrescentar uma nova citação ou relação ao nome existente. Usuários plenos podem criar nomes populares, mas apenas o criador ou um superadministrador pode editá-los. A exclusão não é permitida quando existem citações registradas por outros usuários. Veja o fluxo de curadoria.

Formulários

Consulte a seção de Formulários em Objetos de Atributos, que detalha o uso na interface web e no aplicativo OpenDataBio Collect.

Datas incompletas

Datas para Vouchers, Indivíduos, Medições e Identificações podem ser incompletas, mas pelo menos ano é obrigatório em todos os casos. As colunas date nas tabelas são do tipo ‘date’ e as datas incompletas são armazenadas com 00 na parte ausente: ‘2005-00-00’ quando apenas o ano é conhecido; ‘1988-08-00’ quando apenas o mês é conhecido.

Auditando mudanças

As modificações nos registros do banco de dados são registradas na tabela activity_log. Esta tabela é gerada pelo pacote ActivityLog. As atividades são mostradas em um link ‘Histórico’ fornecido no show.view dos modelos.

  1. O pacote armazena as alterações como json no campo properties, que contém dois elementos: attribute e old, que são basicamente os valores novos vs antigos que foram alterados. Essa estrutura deve ser respeitada.
  2. A classe ActivityFunctions contém funções personalizadas para ler as propriedades do registro Json armazenado na tabela activity_log e encontra os valores para mostrar na tabela de dados History;
  3. A maioria das mudanças são registradas pelo pacote como um ’trait’ chamada dentro da classe. Estes permitem registrar automaticamente a maioria das atualizações e são configurados para registrar apenas os campos que foram alterados, não registros inteiros (opção dirty). Além disso, a criação de registros não é anotada como atividade, apenas as alterações.
  4. Algumas alterações, como de coletores e de identificações indivíduos são registradas separadamente, pois envolvem tabelas relacionadas e o registro é especificado nos arquivos do Controlador;
  5. O registro contém um campo log_name que agrupa os tipos de registro e é usado para distinguir os tipos de atividade e é útil para pesquisar a tabela de dados do histórico;
  6. Dois registros especiais também são feitos para Conjuntos de Dados:
  7. Qualquer download de um Conjunto de Dados pela interface é registrado, então os administradores podem rastrear quem e quando o conjunto de dados foi baixado;
  8. Qualquer solicitação de conjunto de dados também é registrada pelo mesmo motivo

O clean-command do pacote NÃO DEVE ser usado durante uma instalação em produção, caso contrário, apagará todas as alterações registradas. Se executado, apagará os logs anteriores ao tempo especificado no arquivo /config/activitylog.php.


A tabela ActivityLog tem a seguinte estrutura:
{
    "attributes":
    {
        "person_id":"2",
        "taxon_id":"1424",
        "modifier":"2",
        "biocollection_id":"1",
        "biocollection_reference":"1234",
        "notes":"A new fake note has been inserted",
        "date":"2020-02-08"},
    "old":{
        "person_id":674,
        "taxon_id":1413,
        "date":"1995-00-00",
        "modifier":0,
        "biocollection_id":null,
        "notes":null,
        "biocollection_reference":null
    }
}