search

terraref / reference-data

Coordination of Data Products and Standards for TERRA reference data
https://terraref.org
BSD 3-Clause "New" or "Revised" License
9 stars 2 forks source link

Storing field protocols and software code, linking to BETYdb methods, plots, managements. #80

Closed dlebauer closed 7 years ago

dlebauer commented 7 years ago

(from anonymous user)

Yesterday in our local TERRA REF meeting the question arose as to how to document the calculations used to obtain plot-level yield data or any other data where intermediate calculations are made.

As you have seen, there are multiple ways to arrive at a value of yield per unit area, depending on what assumptions are made about effects of plot size and plant stand. In this case, Mike and I would prefer to provide the raw data and the SAS code. Other scientists might want to upload Excel macros or R scripts. Should such information just be uploaded as part of the protocols or is there another way to link information on data processing with uploaded data?

Keep in mind that from our perspective, the phenotype (e.g., aboveground dry matter/m2) might remain the same over multiple seasons but that the calculations could vary. For example, if we continue to improve our planting and seedling establishment, we might drop corrections for stand and variable plot length.

Completion criteria

dlebauer commented 7 years ago

Here is the way we can do this:

  1. When you upload data you can have a trait name like 'height' as well as a method like 'hand measurement'
  2. the method has a field for description. Simple methods and code snippets can be placed in the description field. Each method also has a 'citation'. The citation can reference a person, a citation, or any other public resource (e.g. a github repository or the terraref documentation. Code, excel spreadsheets, macros, etc can all be stored on GitHub. We can discuss how best to organize these, for starters it might be easiest to create a protocols repository. For code that is in the pipeline we have approx. one repository per set of inputs / outputs.

As a reminder, we previously decided that we would use methods from Pérez-Harguindeguy 2013 where they fit the needs of our project.

One thing I am not clear on is how you are correcting for yield. If you are correcting for establishment then perhaps we should have a 'stand biomass' with plot area as a covariate in addition to the yield adjusted for bare ground. Otherwise, two plots with very different establishment could look very different to sensors but have the same 'yield' reported.

PS our server for BETYdb is undergoing maintenance right now. When it is back up I can point you to how we are already storing different methods for measuring height.

JeffWhiteAZ commented 7 years ago

Thanks for the clarification. I would support developing a protocol repository that allows for more complex explanations than in a method description field. Looking at the height protocol examples would be good.

dlebauer commented 7 years ago

@JeffWhiteAZ if you look at the protocols template it has room for more detail. And after compiling the documentation will render latex math. However, most of the field measurement protocols I was given last year fit into a spreadsheet cell.

Before I set up a repository, see if something like protocols.scienceexchange.com or protocols.io would be easier to use. If there is motivation for someone to write up proper protocols, One (or both) of these interfaces might be preferable. The advantage of these is that they make the protocols more easily discoverable and they also make it easier for other groups to share and adapt the protocols without changing the referenced version. I know that there is a lot of interest in a set of standard protocols, so these may provide an appealing and neutral interface.

dlebauer commented 7 years ago

@nshakoor @terraref/developers

from today's notes:

Publishing protocols. We need to choose a platform. We decided the current approach of burying them in documentation is not sufficient. Online platforms provide better opportunities for outreach.

Some sites have 'peer review'. Contributions that are peer reviewed are an important component of scientific promotion etc. However, regardless of the platform, these protocols will be published with peer review. Most allow comments and notes directly in the protocol. Between the teams, other TERRA teams, end users, standards committee, and industry partners we have an open peer review system. Comments / notes / adaptations of the protocols are practical examples of peer review and can be listed accordingly. This is the new path.

A few options we discussed:

Researchers should be able to use any of the above or similar platforms. At first glance, protocols.io looks easiest to use and allows forking.

ghost commented 7 years ago
dlebauer commented 7 years ago

@nshakoor have you made any progress?

ghost commented 7 years ago

protocols.io being tested by @dlebauer - better use for field and benchwork.

ghost commented 7 years ago

@nshakoor - document the protocol for protocol documentation please discuss with david about informing team of this requirement

dlebauer commented 7 years ago

Will use protocols.io, documentation, readme files, and methods table in betydb