How to Share Your Research Data

With so many new policies from funding agencies and journals requiring data sharing, it’s growing more likely that you will encounter a data sharing mandate at some point in time. However, it can be difficult to know how to comply if you are new to such requirements. This is because, while the act of sharing data is not complicated, data sharing comes with new systems and best practices that are unfamiliar to many researchers. So let’s walk through the process of sharing your data so you know what to do when faced with a data sharing requirement.

Policy sources

The two most common places you will encounter data sharing requirements are your funder and the journal in which you publish. A list of US funders with data management and sharing requirements is available from the DMPTool. A list of journals requiring data sharing is available from Dryad. Always refer to the specifics of the policies that apply to you, as they can vary from the general description of data sharing requirements I’m outlining here.

What to share

To satisfy most data sharing requirements, you should share any data that underlie a publication. This means making available any and all data necessary to prove or reproduce your findings. Since data are so heterogeneous, you do have some leeway in the exact form of the data you share. Use your best judgment as to whether your peers will prefer raw data, analyzed data, data in a particular file format, etc. Do be sure to perform quality control on your data and add documentation prior to sharing.

When to share

Data sharing should occur at or slightly after the time you publish the article to which the data belong. Note that a few journals want to see your data during peer review (see below). With a few exceptions, you are not required to share you data before you publish your findings.

How to share

The best way to share your data is to place it in a data repository. Repositories are preferable to sharing-by-request as the repository does all of the work to ensure data persistence and discoverability. A repository is a very hands-off way to share once you deposit the data. Repositories also make data more findable and citable, meaning you’re more likely to get recognition for your work. To find a repository, look for suggestions from your journal, your local librarian, or on the repository lists at DataBib and re3data.

Peer review

While peer review is not the norm for shared data, there are methods available for you to have your datasets peer reviewed. The first is that a few journals look at data as part of the peer review process. More common is publishing your data as a “data paper”. Whereas a normal article describes the analysis done on a dataset, a data paper describes the dataset itself and undergoes peer review in tandem with the data. The reason some researchers prefer sharing data via data papers, besides providing thorough documentation and being peer reviewed, is that data papers receive citations just like articles. To see the journals that accept data papers, refer to this list from the University of Michigan library.

Final thoughts on data sharing

Data sharing is not complicated but it does to require work to clean up your data, add documentation, and deposit your data into a repository (though it does become hands-off at this point). One scientist estimated that he spent almost 10 hours preparing a dataset for public sharing, though he expected that preparation time for the next shared dataset would be shorter. I think that this demonstrates one of the biggest barriers to data sharing: we’re not used to doing it. The systems take time to learn and we have to think about preparing our data for sharing while we’re actively working on them in the middle of a project.

Eventually, everyone will get used to thinking about data as important research products and the systems for sharing data will become more established. In the meantime, I hope this post provides some clarity on complying with new data sharing requirements.

Posted in openData | Leave a comment

Where to Start with Data Management

Managing your research data well feels like a big task. There are so many practices that make up good data management that there are whole classes (Oregon State, University of Minnesota) and curricula (NECDMC, MANTRA) on the topic. There’s even a book on data management for researchers coming out in 2015 that I am very excited about (I’m admittedly biased on this). This profusion of practices is a lot to take in if you’ve never consciously managed your data before. So how does one tackle data management if you are new to the subject?

Rather than try to do everything at once, I always recommend a slow and strategic approach to data management when you are getting started. You can really begin anywhere (the posts on this blog can provide inspiration), but I usually suggest one of the following as a starting point:

  • Make sure you have reliable backups
  • Improve your note-taking practices
  • Decide on an organizational system for your data and use it consistently
  • If you have sensitive data, review your data security plan and update it
  • Check to see if you can read your old data files and update file formats and media as needed

All five of these practices are something that you can tackle without a lot of data management experience and will have a big impact on the safety or ease-of-use of your research data.

Once you pick a topic to work on, dedicate a month to slowly improve your habits in this area. With practices like note-taking and organization, try to make good habits part of your routine. With the other practices like reliable backups and keeping track of old files, work to make sure you’re using the best systems available to you; don’t forget to talk with your coworkers about systems you can use together. Basically, focus on improving one data management practice at a time until you are satisfied and comfortable with your new practice. Then choose another data management practice to focus on the next month.

Data management is really the compilation of a lot of small practices that add up over time, and the more you can make those practices routine, the easier it becomes to manage your data well. But every step you take to improve your data management helps. For example, if the only task you address on my list is adding reliable backups, then your data are safer from loss as compared to before. So put a little conscious effort into managing your data, improve your practices slowly over time, and pretty soon you will discover that you have well managed data.

Posted in dataManagement | Leave a comment

Cloud Backup

I’m going to come right out and say that Dropbox is not a sufficient backup. If all you have are files in a Dropbox folder that are synced to the cloud, you should not consider your files to be backed up and safe. This because your files are now entirely dependent on a company’s business model, one of the main perils of cloud storage, but also because synced cloud storage is not a true backup.

The reason Dropbox is not a good backup relates to how different cloud storage services work and the Rule of 3. The Rule of 3 states that you should have 3 copies of your data, 2 onsite and 1 offsite, for safest storage. The crux of the issue is that services like Dropbox, Box Sync, and OneDrive were designed to provide easy access to content from multiple locations and not to provide dedicated offsite backup. Because your files are synchronized across multiple locations, you really have one “copy” of the data that lives in both the cloud and locally. This is not enough to satisfy the Rule of 3.

With syncing, the method of creation and destruction matters – namely, when you update a file in one location it gets updated universally. Likewise, when you delete a file on your local Dropbox folder, it gets deleted in the cloud and vice versa. So if you are using synced storage and something happens to your local device, there is a chance your synced files in the cloud are at risk. And if Dropbox accidentally loses data in the cloud, as happened with cloud storage provider Dedoose, your local data are at risk.

I wish I could say that this is all theoretical, but people using synced cloud storage have lost data. For example, one researcher lost 8,000 photos both locally and in the cloud after a syncing glitch in Dropbox. Another person lost all his Box files when rolled his account into an unrelated corporate account. The good news is that synced storage services like Box and Dropbox do hold on to deleted files for 30 days, but this is not always foolproof.

So what should you do to make your data safer in this case? Add a backup to this system. Put a copy of your data on a local hard drive in addition to storing it in Dropbox. Alternatively, you can use a cloud storage service that provides independent storage/backup. For example, I use SpiderOak as an offsite backup. SpiderOak monitors my local files and saves a new version of a file to the cloud whenever I update it. This process is automatic, just like with syncing, but my cloud copy is independent of my local copy. If I delete a local file, the copy in the cloud is unaffected and vice versa. This means my cloud storage provides a true offsite backup and I’m more likely to get my files back if something catastrophic happens locally to my computer.

Cloud storage is a wonderful development in terms of convenience and providing offsite backup or access, but you should never rely on the cloud alone. It’s always best to follow the Rule of 3 and get another backup for your data, just in case.

Posted in dataStorage | Leave a comment

Data Dictionaries

Recently, I was reading through Christie Bahlai’s excellent roundup of spreadsheet best practices when I started thinking about documenting spreadsheets. You see, best practices say that spreadsheets should contain only one large data table with short variable names at the top of each column, which doesn’t leave room to describe the formatting and meaning of the spreadsheet’s contents. This information is important, especially if you are trying to use #otherpeoplesdata, but it honestly doesn’t belong in the spreadsheet.

So how do you give context to a spreadsheet’s contents? The answer is a data dictionary. And seeing as I haven’t found a good post on data dictionaries and data dictionaries are right up there with README.txt’s as a Documentation Structure of AwesomenessTM, I obviously need to give them a whole post on this blog.

So what is a data dictionary? A data dictionary is something that describes the data in a dataset. Generally, a data dictionary includes an overall description of the data along with more detailed descriptions of each variable, such as:

  • Variable name
  • Variable meaning
  • Variable units
  • Variable format
  • Variable coding values and meanings
  • Known issues with the data (systematic errors, missing values, etc.)
  • Relationship to other variables
  • Null value indicator
  • Anything else someone needs to know to better understand the data

This list represents the types of things you would want to know when faced with an unknown dataset. Not only is such information incredibly useful if you’re sharing a dataset, but it’s also useful if you plan to reuse a dataset in the future or you are working with a very large dataset. Basically, if there’s a chance you won’t remember the details or never knew them in the first place, a data dictionary is needed.

Lemur Spreadsheet Subset
Lemur Spreadsheet Subset

Let’s look at a real world example from some newly released data from the Duke Lemur Center (data descriptor, dataset). I downloaded the “DataRecord_3_DLC_Weight_File_06Jun14.csv” file from Dryad and found that, while the dataset is very clean (yay!), I can’t interpret all of the data from the spreadsheet alone. For example, what does the variable “AgeAtWt_mo_NoDec” mean or what does the “Taxon” variable code “CMED” stand for? Enter the data dictionary in the form of the README.doc file.

Lemur Data Dictionary Subset
Lemur Data Dictionary Subset

The Lemur data dictionary nicely lays out information on each variable in the dataset. For example, it defines the variable “AgeAtWt_mo_NoDec” as

Age in months with no decimal:  AgeAtWt_mo  value rounded down to a whole number for use in computing average individual weights (FLOOR(AgeAtWt_mo))

It also has a whole separate table listing the various Taxon codes. This is just the type of added context that describes the variables enough to make the data useful. It’s also the type of information that you can’t smoosh into a spreadsheet without ruining the spreadsheet’s order and computability. So this data dictionary is adding a lot of value and context to the data without messing up the data themselves.

The Lemur dataset can be easily understood and reused because it has clean data, well-named variables, and a nice data dictionary. If you are sharing your data publically, or even just with your future self, plan to give your data the same treatment. And if you don’t have time to do all three preparations? Make the data dictionary. You can’t use data you don’t understand.

Now go out and make some data dictionaries!

Posted in documentation | Leave a comment

Dating Your Data (or How I Learned to Stop Worrying and Love the Standard)

I’m going to come right out an admit something terribly nerdy: I have a favorite standard. It’s ISO 8601. My having a favorite standard probably doesn’t surprise you, as I am a person who writes a blog on data management for fun. Why wouldn’t I have a favorite standard? But my having a favorite standard isn’t something for me alone (though I do use the standard often), it’s because ISO 8601 is incredibly useful for data management. Therefore, I want to make my favorite standard your favorite standard too.

The standard ISO 8601 concerns dates, a common type of information used for data and documentation. To understand why this standard is important, consider the following dates:

  • March 5, 2014
  • 2014-03-05
  • 3/5/14
  • 05/03/2014
  • 5 Mar 2014

All of these represent the same date but are expressed in different formats. The problem is that if I use all of these formats in my notes, how will I ever find everything that happened on March 5th? It’s simply too much work to search for all the possible variations. The answer to this problem is ISO 8601.

ISO dictates that all dates should use the format “YYYYMMDD” or “YYYY-MM-DD”. So the example above becomes “20140305” or “2014-03-05”. This provides you with a consistent format for all of your dates. Such consistency allows you to more easily find and organize your data, the hallmark of good data management.

ISO 8601’s consistency is nice in and of itself, but here’s where things get really awesome: when you use ISO 8601 dates at the beginning of file names. This is because dates using this standard sort chronologically by year, by month, and then by date. So if you date all of your file names using ISO 8601, you suddenly have a super easy way to find and sort through information.

Let me give you an example to show you how wonderful this is. I recently cleaned up over 10 years of files for a committee that I am currently on. The committee’s membership changes each calendar year and it was hard to find specific files from previous committees. My solution was to make all the file names start with a date. This makes everything super easy to find and I can now simply ignore content from years I don’t need.

The other great thing about using the “YYYY-MM-DD” format is that you can mix and match how specific your dates are. For example, all of my presentation files live in folders labeled by date. One-off presentations are given an exact date, eg. “2014-04-30_DataManagementWebinar”, while presentations that I give multiple times are only given a year, eg. “2013_CreatingADMP”. I also have files that end up with just a year and a month, eg. “2012-09_Website”. No matter the specificity of the date, all of these files sort chronologically. It’s a beautiful thing.

I highly recommend using ISO 8601 as the way you write dates in your research. It’s a trivially small change, but can have a huge impact in terms of how easy it is to find and use your content. That is data management at its very best.

Posted in dataManagement, digitalFiles | 1 Comment

Anonymization Gone Wrong

Recently, New York City released a dataset containing information on over 170 million taxi rides in the city. While this information is a treasure-trove of information for researchers, the dataset itself is problematic due to anonymization gone wrong. This is just one of many examples of anonymization problems in publicly released data, but a useful one to discuss on the blog.

The key issue is that the taxi dataset contains drivers’ taxi numbers and license numbers. In order to release the data to the public, this information must be translated into a form that cannot be directly linked back to any individual. The data administrators used a common process, hashing, to achieve this anonymization.

Hashing works by performing a prescribed computation process on a textual input (or the bits that make up a file) to turn the input into a (nominally) unique value of consistent length. For example, the MD5 hash function spits out 32-character hashes, transforming the value zero into “cfcd208495d565ef66e7dff9f98764da”. Hashing is generally a one-way computation because it is difficult to get the input value back when you only know that hashed value. Hashing is a popular method for anonymization because a given number always results in the same hash value, allowing for correlation between related, but hashed, information within a dataset. Multiple hash algorithms are available, such as MD5 and SHA-1.

Hashing has a major drawback that is made apparent by the taxi data. Namely, hashing becomes less secure if your input values have a prescribe format. In the case of this dataset, taxi license numbers have one of the following formats (where ‘X’ = letter and ‘9’ = number):

  • 9X99
  • XX999
  • XXX999

Given a prescribed format and a known hash function, it is easy to calculate all of the possible input values, run the hash function, then compare the complete set of hashed values to the values in the dataset. In the case of the taxi data, researchers almost immediately discovered that the data used the MD5 hash function. By computing all 22 million possible taxi license numbers and running the MD5 hash function on them, researchers were able to completely re-identify this dataset.

So does this mean that you can no longer use hashing to de-identify your data? No, but hash functions should not be your only anonymization tool. In the case of the taxi data, one way to improve on the hashing would be to substitute a random number for each license ID, then hash the random numbers. Not only does this make the hashed values harder to re-identify (because the input has no consistent format), but even if the data are re-identified, the random values are not personally identifiable. Note that administrators must maintain a list of IDs and their corresponding random values if they ever want to re-identify the dataset.

Even running personally-identifiable data through an alias may not completely anonymize a dataset. For example, it may be possible to identify drivers and passengers in this dataset by using geographic and timestamp information. In 2000, data privacy expert Dr. Latanya Sweeney showed that the majority of Americans can be identified only by ZIP code, birthdate, and sex. This is what makes the anonymization of research datasets so challenging, because the interaction of variables in the dataset (or between the dataset and outside datasets) can make information personally identifiable.

There is obviously more to anonymizing data that I can cover in one blog post, but the moral of the story is that you should not assume that removing or obscuring variables in a dataset makes your data anonymized. It is much better for your research (and your job security) if you put a little thought into the anonymization process. Proper anonymization is a tricky process, so don’t assume that the bare minimum is sufficient for your data.

Posted in security | Leave a comment