Join the SPLASH Data Standardization Subgroup Launch!

[luis.depombopuerta]

Hello AWG members! @HardwareAWG @AWGall

With @jessica.a.lee’s leadership on the Hardware AWG roadmap, we are launching a SPLASH Data Standardization Subgroup, co-led by @RushiGuppy and @luis.depombopuerta, to improve metadata consistency, searchability, and documentation in SPLASH. This is separate from the Content Subgroup, led by @adhvim (see @NateA’s announcement there).

Goal: define field standards (units, formats, controlled vocabularies), keep the live database and docs aligned, and build on prior discussion in SPLASH Data Standardization and minimum publish fields.

Why join: SPLASH is only as useful as its metadata. Better standards mean hardware that is easier to find, compare, and trust. This is a chance to help set those rules early, while the catalog is still growing.

We need help with: standard units and field formats, reviewing existing fields, parameter documentation, and section organization. No prior SPLASH experience required. If you have domain expertise, ontology experience, or just strong opinions about good metadata, we want to hear from you.

Join us: fill out the interest form by Friday, June 26, 11:00 PM PT (takes a few minutes):

Hardware AWG Data Standardization Interest

Background: Data Standardization Hardware AWG Subgroup Invitation. Contact @RushiGuppy or @luis.depombopuerta with questions.

Looking forward to working with you!

Luis E. De Pombo Puerta (X)
SPLASH Data Standardization Subgroup Co-Lead

[greenboxlabs]

Congrats on launching the Data Standardization Subgroup! This is exactly the kind of groundwork that makes a hardware catalog usable, and we are glad to see it happening early.

Our team is heads-down this cycle, so we cannot formally commit to the subgroup right now. However, we care deeply about this effort. We reviewed the current field workbook end to end and would love to stay on the list as things develop.

To provide immediate value rather than just cheering from the sidelines, here are our concrete takeaways from the current version. Please use whatever is helpful:

• Data Rate should be a rate, not a size. It is currently typed in Kilobytes. A data rate needs a time base. We suggest kB/s, MB/s, or GB/s, while storing the canonical value in byte/s. Modern streams exceed kilobytes, so larger magnitudes matter.

• Add sub-gram mass units. Mass currently binds to kg only, but bio payloads operate on a milligram or microgram scale. We suggest adding g, mg, and µg. The Units Ontology has terms for all four.

• Radiation shielding needs more than a Boolean. A yes/no cannot accurately describe shielding. Users need materials and areal thickness. We suggest a structured free-text field for materials and min/max areal density in g/cm² (e.g., Al 5-15 g/cm²; polyethylene 1-5 g/cm²), plus an optional schematic link. You can keep TID tolerance as a number in rad/krad, gated behind a COTS vs. rad-hard dropdown.

• Lock one format per range field. Since min/max are already separate numeric columns, treat the display string as derived. Use formats like “4 to 40 C” or “50 to 85 %RH” with a clear “ambient” or “N/A” for uncontrolled fields.

• Rename fields to sharpen intent. Change “Research Area” to “Research Purpose”. We also suggest splitting “Specimen Capacity” into “Specimen Size” and “Specimen Quantity” because they represent different questions.

• Set character limits on free-text fields. Even a generous cap like 500 characters for Notes keeps the catalog ingestible downstream.

• Close the Units-Ontology gaps. The units sheet is very clean, but a few used units are not bound yet. Look into Pa (pascal), days, and Cubesat U. You might declare Cubesat U as a project-local unit with a clear definition. You will also need to bind the kByte/s composite from the first point.

• Address the missing ontology rows. For the unmapped rows (Planetary Protection, Life Detection, Nutrient Production, Fluid Mechanics), ENVO, OBI, NCIT, and CHEBI are strong candidates for bindings.

Finally, we found it handy to normalize the workbook into a machine-readable schema. This allows submissions to be validated before they are sent. If the subgroup would find that useful, we are glad to share our approach.

Thanks for driving this forward. We will keep an eye on how it develops.

Lisa and the team at GREENBOX Labs

[RushiGuppy]

Hi Lisa + GREENBOX Labs team!

Thank you so much for the in-depth feedback. I am Rushil and I am leading this subgroup (Alongside @luis.depombopuerta) as an Intern at NASA Ames, I have addressed below a couple of the points that were brought up.

1. Data Rate should be a rate, not a size - I was not able to find the ontology for KB/s. Therefore the intent of this field would still be Kb/s, but the user enters the KB value. it is essentially the same field but a workaround without the exact Ontology definition for KB/s. i have clarified in the Parameter definition and Notes on this.

2. Add sub-gram mass units - adding different units for one parameter has been a topic of discussion before. the general consensus we (Data standardization subgroup) have reached is that for this first version we will focus on only one unit per field for simplicity. Adding functionality for additional units may be a discussion for later (probably after my internship ends). Most of the current mass data in splash is measured in kg therefore we have put a hold on the multi-unit functionality.

3. Radiation shielding needs more than a Boolean - Another topic of discussion we had. In this open-source SPLASH testing visualization (which you can run locally since I can’t host it), we actually have this exact suggestion. However due to simplicity, this might be another update down the road

   

4. Lock one format per range field. - This is more for the software team rather than data standardization, the schema being designed here is keeping in mind of how this data will be stored in the backend and also for a possible API.

5. Rename fields to sharpen intent. - great suggestion! will make a note of that.

6. Set character limits on free-text fields - I added this in the Notes column for each of the Notes parameter, thanks for noticing!

7. Close the Units-Ontology gaps - Ah, i created that unit ontology sheet only for Ingestion (before we even had the pressure min and max values) and added the Pa to the visualization tool manually. I updated the sheet accordingly but I will delete that sheet since every unit has the ontology def linked to it directly on the sheet.

8. Address the missing ontology rows - This is going to be future work, once we have the structure set for ontology we plan to add these ontologies later on

9. Normalize the workbook into a machine-readable schema - I would love to see this approach! Would you be willing to join our weekly tuesday 10:00am Pacific time meeting to show this?

Thanks for the suggestions!

Rushil

[greenboxlabs]

Thanks Rushil, great to meet you. It is great to see how much of it is already moving. We have a few quick reactions and an update on the schema question.

• Data Rate: The Notes-column workaround is a fine bridge while there is no KB/s term. One small thing to lock down so downstream users are not confused is to pin the label to KB (kilobyte) versus Kb (kilobit) explicitly, since they differ by a factor of 8. If you ever want the canonical value to be machine-comparable later, storing it as byte/s under the hood costs nothing now.

• One unit per field for v1: This is totally reasonable given most SPLASH mass is in kg. Whenever multi-unit functionality does come up, the Units Ontology already has g, mg, and µg ready, so it will be a small lift.

• Radiation shielding: It is great that the structured version already lives in the testing visualization.

One item we would gently re-flag is the range format. You are right that rendering is a software concern. Our point is just that the schema contract itself should declare the single derived display format (e.g., “4 to 40 C”). This ensures whatever the backend or the future API emits is consistent by construction rather than by convention. It is a one-line-per-field addition to the schema, not app work.

On normalizing the workbook into a machine-readable schema, we are glad it resonated. We keep a machine-checkable version internally to validate our own exports before they go out. That discipline of catching a bad submission before it enters the catalog is really the whole payoff. We are heads-down with a few larger federal initiatives this quarter, so we cannot commit to the standing Tuesday slot. However, we are glad to accept a calendar invite tentatively and join when schedules allow, and happy to give field-level feedback via the portal.

Lisa