Research Data

Good quality documentation allows others to understand and use your data. Documentation can include:

• Interview protocols
• Questionnaires & interviewer instructions
• Codebook or data dictionary
• Information sheets, Consent forms, Ethical approval
• Database schemas
• Methodology reports
• Provenance information about sources of derived or digitized data

The project-level documentation explains the aims of the study, what the research questions/hypotheses are, what methodologies were being used, what instruments and measures were being used, etc. In the accordion the questions that your project-level documentation should answer are stated in more detail:

• For what purpose was the data created
• What does the dataset contain?
• How was data collected?
• Who collected the data and when?
• How was the data processed?
• What possible manipulations were done to the data?
• What were the quality assurance procedures?
• How can the data be accessed?

Collecting this information in one document will help where new members join a research team, when writing up a paper or if you plan on sharing your data at the end of the project.

Data-level or object-level documentation provides information at the level of individual objects such as pictures or interview transcripts or variables in a database. You can embed data-level information in data files. For example, in interviews, it is best to write down the contextual and descriptive information about each interview at the beginning of each file. And for quantitative data variable, value names can be embedded within the data file itself.

For quantitative data document the following information is needed:

• Information about the data file
  • Data type, file type, and format, size, data processing scripts
• Information about the variables in the file
  • The names, labels and descriptions of variables, their values, a description of derived variables or, if applicable, frequencies, basic contingencies etc. The exact original wording of the question should also be available.
  • Variable labels should:
    • Be brief with a maximum of 80 characters
    • Indicate the unit of measurement, where applicable
    • Reference the question number of a survey or questionnaire, where applicable

For qualitative data document the following information as needed:

• Textual data, for example interviews, include key information of participants such as age, gender, occupation, location, relevant contextual information
• For qualitative data collections (for example image or interview collections) you may wish to provide a data list that provides information that enables the identifying and locating of relevant items within a data collection:
  • The list contains key biographical characteristics and thematic features of participants such as age, gender, occupation or location, and identifying details of the data items;
  • For image collections, the list holds key features for each item;
  • The list is created from an initial list of interviews, field notes or other materials provided by the data depositor.

Research data files and folders should be labelled and organized in a systematic and consistent way so that they are easy to find, both for you and others in your research team. There is no one recommended way to name your files and folders, but consistency is key.

It’s generally useful to aim for file and folder names which are concise, but informative – it makes life easier if you can tell what’s in a file without having to open it. 

• Avoid special characters like &, %, $, #, @, and *. Just use letters and numbers.
• Do not make file identity dependent on capitalization unless implementing camel case (e.g. fileName.xml).
• Never use spaces in filenames – many systems and software will not recognize them or will give errors unless such filenames are treated specially. Use an underscore _ instead of a space.
• Use short file names. For your sake and the sake of systems that’ll fail if you give it like a 50 character file name.
• Use 001, 002, 003 instead of 1, 2, 3 to help sort and search through the data more effectively.
• Choose file names that are recognizable to humans and that make sense within the project environment
• Be consistent

   

Elements of a file name can include:

• A project acronym

• Content description

• File type information

• Date (YYYY-MM-DD)

• Creator name or initials

• Version number

• Status info, e.g. draft

Operating systems usually default to sorting files alphabetically, so it can be helpful to think about what comes at the start of the file name – is it more useful to order the files by date, by author, or by subject, for example?

The benefit of consistent naming of data files is that it is easier to identify all files connected to one data collection event (e.g. one interview). The files related to one collection event (e.g. audio tape, its transcription and photographs that were taken by the interviewee) can be connected by the file name.

Example:

• 20190311_interview2_audio.wav
• 20190311_interview2_trans.txt
• 20190311_interview2_image.jpg

Version control is "the management of changes to documents, computer programs, large web sites, and other collections of information." (Wikipedia). It's a way that we can keep track of our projects across time, space, different users, and different systems. Nothing that is version controlled is ever lost, and there is a record of changes, who made them, and when. Systems with version control can notify users when there is conflict between one person's work and another's.

Managing different versions of your data can be achieved by:

• Uniquely identifying different versions of files using a systematic naming convention, such as using version numbers or dates
  • Record the date within the file: 20190902_documentation_for_my_data
  • Include a version number in the file name: Documentation_v2
  • Include information about the status of the file, e.g. "draft" or "final," as long as you don't end up with confusing names like "final2" or "final_revised".
  • Include information about what changes were made, e.g. "cropped" or "normalized".
• Using version control facilities within the software you use
• Using file-sharing services with incorporated version control
• Designing and using a version control table