Discover our blogs

Aerospace | Cranfield University

Aerospace

Agrifood | Cranfield University

Agrifood

Alumni | Cranfield University

Alumni

Careers | Cranfield University

Careers

Careers | Cranfield University

Defence and Security

Design | Cranfield University

Design

Energy and Power | Cranfield University

Energy and Sustainability

Environment | Cranfield University

Environment

Forensics | Cranfield University

Forensics

Libraries | Cranfield University

Libraries

Libraries | Cranfield University

Manufacturing and Materials

Libraries | Cranfield University

School of Management

Libraries | Cranfield University

Transport Systems

Water | Cranfield University

Water

Homepage / Data documentation – what and why

Data documentation – what and why

22/09/2016

City map with a legend

Just as a map becomes much easier to read when you have a legend explaining the symbols, data is much easier to comprehend when you have descriptive and contextual information. For example, while you’re using your research data, you’ll know what your variable names are short for, and what different missing value codes mean. But if you want to reuse it in a few years’ time, will you still be certain? Or if another researcher uses your data, will they be able to understand it without needing to ask you questions? Maybe you’ve experienced frustration yourself, when you want to incorporate existing data into your research, but it wasn’t made available with sufficient information and you’ve had to spend time contacting the creator.

Making documentation available alongside your data is therefore a key step to ensuring its long-term usability and value, both for you and others (which might lead to extra citations). Documentation can be as simple as one text file, in which you’ve noted all the key contextual information about the data and the project. Some elements you might want to include are:

  • Study-level information
    • Data collection methods, such as instruments used, sampling methods, scales, geographic/temporal coverage, etc.
    • Data processing methods, such as validation, checking, cleaning, calibration procedures, etc.
  • Data-level information
    • Names, labels, descriptions, and units for all variables and fields.
    • Explanation of codes, including reasons for missing values (not applicable/not provided/not recorded/error/etc).

With data-level information, you may be able to include enough information in the data files themselves (e.g. in table headings in a spreadsheet). Otherwise, you might want to store a separate explanatory file alongside your data file(s). You could use our template readme.txt file to note all the necessary elements you want to include, perhaps adding to it as you work through the project.

Or you might benefit from writing what’s called a “data dictionary”, basically a legend to your data. This great blog post on data dictionaries explains it in a nutshell, and highlights the benefits, whether sharing data with others (in or outside your project team) or just your future self. And remember that if you’ve entered this information into a tool such as SPSS, you should be able to export it to a file to store with your data (e.g. in SPSS v23, File > Display Data File Information > Working File > print, and print to pdf, or use the File > Export option in many screens to export to a more usable format such as txt).

So, when depositing your data in a repository, remember to include sufficient documentation for others (or your future self!) to understand it so no questions arise.

 

Image: City map by Mathieu Pellerin, CC-BY-NC-SA 2.0. 

Written By: Georgina Parsons

Categories & Tags:

Leave a comment on this post:

Sign up for more information about studying master’s and research degrees at Cranfield

Sign up now
Go to Top