Gerenciamento de Projetos

Defina a responsabilidade pelo projeto, a distribuição de identificadores e as transferências antes que várias pessoas registrem dados.

Defina uma única fonte de referência

Designe um dispositivo para manter a cópia oficial do projeto. Esse dispositivo guarda a lista principal de táxons, o pessoal e as definições de campos personalizados. Ele distribui as atualizações aos demais dispositivos, que não editam essas definições. Se os espécimes compartilham os mesmos locais, coordenadas e eventos, o dispositivo oficial também guarda esses registros. Os outros dispositivos escaneiam o QR ou importam a cópia oficial e acrescentam seus próprios espécimes, mas não editam os registros compartilhados.

A mesclagem de um projeto deve ser feita pelo dispositivo oficial. É ele que revisa os conflitos de UUID e as escolhas por seção.

Nomeie e identifique o projeto

Use um nome reconhecível, como Patah Mammals, e registre as datas nos campos de data do projeto. O UUID identifica o projeto nas transferências; é distinto do número de catálogo do projeto e do Field ID legível do espécime. Recriar um projeto com o mesmo nome não recria seu UUID.

Dê aos locais IDs estáveis e mantenha seu significado na descrição da localidade. Consulte nomes de locais e coordenadas.

Combine as convenções de Field ID

Escolha a convenção adequada ao seu protocolo de coleta. Os Field IDs de projeto servem a uma sequência compartilhada de processamento; os Field IDs de pessoal servem ao trabalho organizado pelas sequências individuais dos catalogadores.

O NAHPU não sincroniza dispositivos automaticamente. Isso é proposital, para que todo compartilhamento de dados seja deliberado e revisado.

Documente as passagens de trabalho e verifique duplicatas após as transferências. Os UUIDs ajudam a distinguir registros, mas não impedem Field IDs legíveis duplicados nem espécimes com etiqueta trocada.

Como decidir qual Field ID usar

Se você está começando um laboratório, ou o seu laboratório ainda não tem uma convenção padrão de Field ID, em nossa experiência os Field IDs de pessoal são adequados ao processamento paralelo de espécimes, quando várias pessoas preparam espécimes e registram dados nos próprios dispositivos. Eles trazem menos risco de duplicação de identificadores. Um Field ID de projeto é mais apropriado se os dados são registrados em um único dispositivo e a preparação dos espécimes segue uma única sequência, com cada pessoa da equipe cumprindo um papel diferente no fluxo de trabalho, como coletar tecidos, fotografar, preparar espécimes-testemunho etc.

Gerencie as contribuições

Estabeleça uma identidade de projeto comum antes de distribuir o trabalho. Defina responsáveis pelo pessoal, táxons, vocabulários e definições de campos personalizados compartilhados. Combine quando cada dispositivo deixa de editar para uma passagem de trabalho e quem revisa o projeto combinado.

• Import project, na tela inicial, leva um projeto para outra instalação.
• Merge project, dentro de um projeto existente, combina contribuições; revise conflitos de UUID e escolhas por seção. Não force uma incompatibilidade de UUID apenas porque dois projetos têm nomes parecidos.
• Guarde os pacotes de origem e um backup anterior à mesclagem até que o resultado seja conferido.

Registre quem forneceu e revisou cada pacote, e o que foi decidido em cada passagem, enquanto a equipe ainda está reunida. Você pode registrar na narrativa os detalhes que explicam uma mesclagem, para que fiquem junto dos dados. Uma nota escrita no acampamento vale mais que uma reconstrução tentada no ano seguinte.

Entropia da informação

Michener et al. (1997) descrevem isso como resistir à entropia da informação: o conteúdo interpretativo de um conjunto de dados se degrada com o tempo, à medida que as pessoas que o guardavam na memória se dispersam.

Programe e verifique os backups

Exporte o projeto ativo em intervalos combinados, por exemplo ao fim de cada dia de campo e antes de uma passagem de trabalho importante. Escolha ZIP ou TAR.GZ quando os arquivos disponíveis do projeto precisarem acompanhar os registros; JSON.GZ os omite. Avisos de arquivo ausente exigem investigação, porque um pacote não pode incluir arquivos que já estão faltando.

Use Backup database para a recuperação de toda a instalação e antes de mesclagens ou curadoria de grande porte. Escolha a frequência conforme o trabalho em risco, o armazenamento e a energia disponível; tamanho e duração dependem da instalação.

Planeje contra o desgaste, não apenas contra a catástrofe. Os dados se perdem sobretudo por discos mortos, mídias ilegíveis, arquivos sem identificação e pessoas que saem, e não por um único evento dramático. Guarde cópias datadas fora do dispositivo de registro, incluindo outro dispositivo físico quando não houver internet. Um envio para a nuvem só está completo depois de confirmada a cópia remota.

Teste periodicamente a recuperação em outra instalação e compare contagens de registros, relações, identificadores e arquivos. Essa restauração é o único passo que distingue um backup de um arquivo que você nunca abriu. Mantenha as versões anteriores até que a cópia mais recente seja verificada.

Nomeie os pacotes com clareza, por exemplo PatahMammals_transfer_20260908.zip. Um nome que carrega o projeto, a finalidade e a data continua interpretável quando é a única cópia que sobrou. Siga o guia de transferência de projetos para as opções de transferência e o guia de exportação para a substituição do banco de dados.

Referências

Chapman AD (2005). Principles of Data Quality. GBIF Secretariat, Copenhague.

Michener WK, Brunt JW, Helly JJ, Kirchner TB & Stafford SG (1997). Nongeospatial metadata for the ecological sciences. Ecological Applications 7:330–342.