neon to nmdc-schema mappings

[turbomam]

• I will define a neon.schema prefix in the nmdc-schmea, with an obvious placeholder expansion
• @bmeluch and others will create a assets/neon_nmdc_term_mappings.tsv document in the nmdc-schema repo with four/five columns
  • nmdc_class
  • nmdc_slot
  • neon_table
  • neon_column
  • notes?
• I will write some code that asserts mappings in slot_usages like

mappings:
- neon.schema:<neon_table>.<neon_column>

[turbomam]

Nice work, @brynnz22 and @bmeluch

Are you requesting that dna_concentration and dna_absorb1 should be attributes of the Extraction process? I suggest associating those slots with the ProcessedSample that actually has those characteristics. Maybe we should relocate sample_mass too.

Think about it this way: if a schema had a Cooking processes, and a served_to slot that pointed to a Person, then a satisfaction slot should be associated with the Person, not the Cooking.

It doesn't matter how our data source models the data, especially if it's coming form relational tables, which are notorious for mixing concerns. It's our responsibility to determine what entities have what qualities, and the nmdc-schema supports doing that in a way that reflects reality better than most relational databases.

Sometimes you can double check your intentions by looking at the other things that use those slots. dna_concentration and dna_absorb1 are only associated with Biosample, which is a MaterialEntity, not a PlannedProcess

[brynnz22]

@turbomam We were discussing which ones it belongs to, and ProcessedSample makes a lot of sense. I think since sample_mass was in the Extraction class, we thought those should go in there too. But it makes sense to move those slots into ProcessedSample!

[aclum]

Are we done with this?

[aclum]

@turbomam are we done with this?

[turbomam]

Might want to revisit this some day