We need your feedback for SPLASH Data Standardization!

AWG Projects Hardware AWG Open Projects
1

Hello @HardwareAWG and all else interested @AWGall :waving_hand:

Ever since the meeting in June, there has been a tremendous progress on Data Standardization. Although everything is not complete yet, I want to give a huge thank you to everyone who has contributed to this effort.

As presented in the July AWG meeting, there are still some uncertainties in how certain data parameters should be standardized and the information it should store in SPLASH. This is where I would love your feedback as that is what makes SPLASH better for every user, including you.

Linked at the bottom of this post is the spreadsheet that Data standardization is being planned on. It is a complex document so I will break the columns down first then ask some guiding questions to help you all think of feedback to give. There also is a gitlab link at the bottom for you to pull and visualize. Please do not try to push/merge code especially to main.

Columns

  1. Section - These are the different sections of Data in SPLASH. Currently SPLASH has General, Specifications, Research. Logistics, and Learn More. This standardization expands these sections to be more accurate and focus on specifics of the parameters. The “Section Name Parameters” Tab in Google sheets give a description for each section.
  2. Parameter - These are the different data parameters like mass or size on SPLASH.
  3. Drop Down/multi-select Values (If Applicable) - Some parameters used to be free text box. We plan to make them dropdowns or multiselect options (select all that apply) to help mitigate the unstructured entries into the textbox to help filterability and query. Not all parameters have this. For the parameters that don’t, you will only see this column have “-----------------------”. However for the parameters that are dropdown/multiselect, they will have the first value next to it be “---------------” to make sure there is a row that has the description for the parameter, then the next rows are the actual dropdown/multiselect values itself. The parameters that have multiselect and dropdown options will be vertically merged for readability. An example will be shown below
  4. Data Type - Currently most parameters in SPLASH have only textboxes where instruments can have long sentences even in sections that should only require numbers. To standardize, we implemented structured data types that will be strictly enforced upon submission an instrument. Examples of value are Dropdown, Multi-select Dropdown, Float, List[String], String, etc.
  5. Units - If applicable, enforce a unit such as centimeter or kg for certain parameters
  6. Description - The description of the parameter and values.
  7. Ontology - The ontology dictionary where the assigned class is from
  8. Ontology Accession ID - accession link to class that is assigned to parameter/value
  9. Notes - Any notes only for standardization (this column is not going in SPLASH). Reading these are helpful if you are confused.

Here is an example of an entry:

image

This is the Research Area parameter in the General section (replacing Category). It takes up 3 rows: rows 5-7. Row 5 is the parameter information with the data type, units (N/A), the description, the Ontology it belongs to (SLSO), Ontology accession ID (the link), and notes for information. Rows 6-7 are the 2 parameters with their datatype (they are an Option of the multiselect dropdown), their respective descriptions, etc.

Guiding Questions

  1. For the Specimen capacity parameter, what is the most organized way to represent how many specimens can fit on an instrument especially if the instruments can support multiple organisms
  2. What units are we missing?
  3. Are the definitions consistent with the parameter name and what data is being asked for by the user?
  4. Does the section that a parameter is in makes sense? should it be moved to a difference section?
  5. Are there dropdown values we missed?
  6. Is a parameter too vague or trying to capture too much information?
  7. Given the instrument export, is there a parameter changed in such a way that a significant amount of information will be lost after standardization (Ex: a parameter with Long strings as data in the instrument export will now turn into just a yes/no checkbox)? Consider the case where the “lost” data can be put into the notes category, will this be adequate in standardization + minimizing data loss?
  8. Do you see a parameter that is not assigned an ontology class and you know what ontology class to assign it?
  9. Does a parameter require a better datatype that will not allow for unstandardized data?

Here is the link to the spreadsheet: SPLASH Data fields for Data Standarization - Google Sheets

Link to gitlab: Rus Gup / SPLASH-Data-Standardization-Visualization-Tool · GitLab

You should be able to comment (and it is highly encouraged to comment) on cells. Please reply to this post if you have any questions.

Due to the nature of this project and my internship dates, this period of feedback will only last to Tuesday 8/4 5pm PT.

Thank you all in advance for your contribution to this major SPLASH improvement.

2 Likes