Issues with ongoing data

Guidelines for common occurrences with ongoing data collections, such as changes to the collection protocols [methods|table|measurements], instrument location or measurements are added.

Issue: Supposedly, this is a new version of one of our time series data products but it doesn’t look anything like I already have.

  • Solution: Confirm that you have the right data entity. Send the lab a link to the dataset this is supposed to update. Ask why the change, and take steps to stabilize the formats of data entities that are intended for sharing.
  • Example: in 2018, SBC completely changed the modeling algorithm for predicting kelp net primary production to include previously unresolved sources of biomass loss. So we redesigned the data package for those data. The redesigned data package was so different, that we did not want to use the same identifier. Instead, we capped off the old dataset and started a new one (see below, “Capping off”). We also requested that the old dataset be removed from the index (see below, “indexing”).
    • Capped off data package: knb-lter-sbc.21.18
    • replaced by: knb-lter-sbc.112

Issue: The instruments were moved to a new location, that ostensibly represents the same region.

  • Solution: Ask why the move, and find out if data should be considered continuous. In the example, we started a new dataset to make it clear that any integration was up to a user.
  • Examples:
    • pre-move: knb-lter-sbc.2001
    • post-move: knb-lter-sbc.2002 (most recent revisions)

Issue: A new measurement was added to the suite.

  • Solution: Add a new column for the new measurement(s). It’s up to you where to put it. If your system (and the lab’s) makes it easy to keep similar measurement together in a table, do so, because users will appreciate it. If not, put it at the end.
  • Examples:
    • 23 columns: knb-lter-sbc.50.6
    • 24 columns: knb-lter-sbc.50.7

This material was adapted by EDI from: