No decurso da investigação

A escolha dos formatos dos ficheiros influencia diretamente a possibilidade de preservar, reutilizar e partilhar os dados de investigação a longo prazo. De forma geral, são recomendados os formatos abertos, bem documentados, amplamente utilizados na comunidade científica, independentes de um software pago.

Os formatos proprietários, isto é, aqueles que são dependentes de um software de subscrição, como a Microsoft Office, podem ser usados na fase de dados ativos, sobretudo quando são necessários para análise (por exemplo, ficheiros de software estatístico ou de equipamentos específicos). Contudo, no momento de finalizar o projeto, deve-se exportar os ficheiros relevantes para formatos recomendados, garantindo assim a preservação e a reutilização futura dos dados.

Definir uma convenção de nomes desde o início do projeto é essencial para garantir que os ficheiros sejam facilmente identificáveis, compreensíveis e pesquisáveis.

Boas práticas na criação de nomes de ficheiros

·       Nomenclatura breve e específica.

·       Ordenar os elementos do mais geral para o mais específico.

·       Utilizar abreviações significativas e consistentes.

·       Separar elementos utilizando underscore (_), hífen (-) ou letras maiúsculas para cada nova palavra.

·       Evitar espaços, pontos finais e caracteres especiais (como ?!& , * % # ; * ( ) @$ ^ ~ ‘ { } [ ] < >).

·       Registar as datas no formato ISO 8601: YYYYMMDD (e, se necessário, a hora: HHMMSS). Este formato garante que os ficheiros sejam ordenados cronologicamente.

Exemplos:

YYYYMMDD_ProjectAcronym_Title_VersionNumber

ProjectAcronym_DataType_Title_VersionNumber_YYYYMMDD

Uma estrutura de pastas bem planeada poupa tempo, facilita a navegação e ajuda a localizar rapidamente ficheiros. É especialmente importante em projetos colaborativos, onde várias pessoas acedem e guardam informação em pastas partilhadas.

Boas práticas para estruturar pastas

· Planear a estrutura de acordo com o projeto. A organização das pastas deve refletir as principais fases do projeto (por exemplo: recolha de dados, análise, resultados) e os tipos de dados envolvidos (brutos, tratados, transcritos, analisados, etc.).

· Definir um esquema de nomes. Tal como nos nomes de ficheiros, as pastas devem seguir convenções consistentes, simples e coerentes.

·  Documentar a estrutura. Criar um ficheiro README na pasta principal, onde se descreve a lógica da estrutura e as convenções utilizadas.

· Reutilizar o mesmo modelo. Sempre que possível, adotar a mesma estrutura em diferentes locais de armazenamento (por exemplo, servidor institucional, disco local ou serviço de cloud).

· Limitar a profundidade. Evitar mais de quatro níveis de subpastas — regra prática que ajuda a manter a navegação simples e intuitiva.

·  Classificar de forma lógica. Dividir pastas por etapas do projeto (Ex.: 01_RecolhaDados, 02_Análise, 03_Resultados) e por categoria de dados (Ex.: DadosBrutos, Tratados, Documentos, Códigos).

As pastas onde estão alojados os ficheiros de dados devem incluir um ficheiro README, um documento em formato texto (.txt) ou markdown (.md), com a informação que permita que os conteúdos sejam corretamente identificados de forma rápida e informativa. Este documento deve aparecer no topo da pasta, devendo nomeá-lo, por exemplo, 0_README.

Conteúdo recomendado para um README

• Informações gerais do projeto: nome, objetivos, período de execução, equipa envolvida e contactos principais.

• Estrutura de pastas e ficheiros: diagrama simples ou lista explicando a organização (ex.: 01_RecolhaDados/DadosBrutos/).

• Convenções de nomeação: regras para nomes de ficheiros e pastas, incluindo abreviações e formatos de data.

• Descrição dos dados: origem, métodos de recolha, software utilizado, formatos de ficheiros e eventuais transformações aplicadas.

• Instruções de uso: passos para reproduzir análises, dependências de software e notas sobre qualidade ou limitações dos dados.

• Histórico de alterações: registo de versões importantes e mudanças feitas (data, autor, descrição).

O ficheiro README deve ser usado não só no contexto da organização interna do projeto, mas também deve acompanhar os dados no momento da sua publicação em repositórios. Enquanto documento que acompanha o dataset, o ficheiro README também deve incluir informação sobre:

Dados de contato dos responsáveis pelo dataset.

Licença de uso dos dados.

Contexto e objetivos da investigação.

Fontes utilizadas e validação dos dados.

Outra documentação de apoio útil, quer no momento do processamento e interpretação dos dados, quer no momento da divulgação dos dados, é o dicionário de dados. Este costuma ter um formato tabular ou de folha de cálculo (por exemplo, ficheiro CSV), descreve de forma clara cada variável ou coluna de um conjunto de dados. Pretende:

·       Facilitar a compreensão e reutilização dos dados dentro e fora da equipa.

·       Reduzir erros na análise, ao clarificar unidades, códigos e categorias.

·       Apoiar a documentação para publicação de dados ou submissão em repositórios.

Exemplo:

Boas práticas para um dicionário de dados

Criar o dicionário em paralelo com a recolha de dados, não no fim.

Atualizar sempre que se adiciona, remove ou transforma variáveis.

Guardar o ficheiro junto dos dados correspondentes.

Usar um formato aberto (por exemplo .csv ou .xlsx bem estruturado, sem formatação decorativa).

A gestão de versões, ou controlo de versões (version control) permite acompanhar as alterações nos ficheiros ao longo do tempo. Garante que se identifica facilmente a versão mais recente e que se recuperam versões anteriores sempre que necessário.

Para dados simples, basta adicionar um número de versão ao nome do ficheiro. A convenção mais clara utiliza:

● Números inteiros para revisões maiores (ex.: V1, V2).

● Decimais para alterações menores (ex.: V1.1, V1.2, V2.1).

Para cumprir o RGPD e proteger os direitos dos participantes, é essencial aplicar técnicas adequadas de proteção sempre que se recolhem dados pessoais ou sensíveis na investigação.

A pseudonimização substitui identificadores pessoais por códigos ou pseudónimos. É possível voltar a identificar o titular dos dados recorrendo à chave de codificação.

 Por ser um processo reversível, exige maior controlo no acesso aos dados brutos e maior cuidado na encriptação da chave de códigos, que deve ser guardada separadamente em acesso restrito.

A anonimização remove permanentemente identificadores diretos (ex.: nome, NIF, data de nascimento) e indiretos (a combinação de identificadores, como a idade e localização que possam permitir a identificação). Os identificadores são categorizados de forma abrangente. Por aplicar um processo de categorização, e não de codificação, não é possível voltar a identificar o participante, o que significa que estes dados perdem o estatuto de dados pessoais e podem ser usados livremente.

Para saber mais sobre a proteção de dados e questões jurídicas que lhe estão associadas, veja a página Dados Sensíveis.

A implementação de um sistema de cópias de segurança constitui uma medida essencial para prevenir a perda de dados de investigação resultante de eliminação acidental, avaria de hardware, roubo ou danos nos equipamentos.

A Regra 3-2-1 representa a abordagem padrão para a gestão de cópias de segurança em contexto académico:

● 3 cópias dos dados;

● 2 tipos de suportes de armazenamento distintos;

● 1 cópia armazenada fora do local principal (geograficamente separada).