Update submission schema so that hardcoded list of classes can be removed from nmdc-server

[pkalita-lbl]

Currently nmdc-server maintains a hardcoded list of classes along with meta-information like display names and display statuses: https://github.com/microbiomedata/nmdc-server/blob/ccd899bf07baae6abac7049a20202d6908c72c60/web/src/views/SubmissionPortal/harmonizerApi.ts#L60 There isn't any reason why this information couldn't be derived from the schema directly with some updates. In particular:

• displayName should be able to be derived from a class's title. Review the existing titles, see if they align, and update if needed.
• schemaClass and sampleDataSlot could be derived from looking at the slots of the SampleData class and the ranges of those slots. Double-check that, but there may not be any schema changes needed here.
• status could be placed in a custom annotation on the classes. LinkML has a status metaslot https://linkml.io/linkml-model/1.7.x/docs/status/ but I'm not sure that's what we want to use here. In fact it may be worth coming up with a new name for the annotation to avoid confusion.
• Add real descriptions to the interface classes (see: https://github.com/microbiomedata/submission-schema/blob/fff9173fc4aa42a609fcb7e86b3f71c0a10d5128/src/nmdc_submission_schema/schema/nmdc_submission_schema.yaml#L18911)

[mslarae13]

@pkalita-lbl what is the submission-schema action? Do we need to add aliases? Or is this really a serve action? "Update server ingest code to leverage NMDC submission schema.

[pkalita-lbl]

what is the submission-schema action?

The bullet points represent things that should be done in the submission schema (update title and descriptions, add annotations).

Do we need to add aliases?

I don't think so.

Or is this really a serve action?

Once this work is complete in the submission schema there is code that can be removed and/or simplified in nmdc-server, but that's a separate step.

[turbomam]

I have some wishes but probably wont have a good solution for #213 in the next 24 hours. @pkalita-lbl and I have discussed some of this and agree on the underlying principles as far as a I can tell

• agreed: these mappings would ideally not live as a typescript file or in the nmdc-server codebase
• if any new mappings are required, they should be as similar to the actual MIxS Extension class names as possible. We shouldn't be coming up with still more lexical forms of these names (in MIxS, submission-schema, nmdc-server, something new...)
• the mapping resource (or native LinkML representation) would acknowledge all of the MIxS Extensions. Currently there are some that aren't accounted for in the "published" and "disabled" status subsets. So I would propose another status like "hidden"
• ideally the technical solution wouldn't require LinkML annotations. Maybe structured_aliases?
  • may not be readily amenable to a schemasheets implementation

[turbomam]

I have prototyped a MIxS Environments/NMDC DH Interfaces TSV mapping file here, in response to this request

That mapping also includes columns for the MIxS environmental triad slots. They aren't relevant to this issue.

[turbomam]

see also

• Does nmdc-server know about all current MIxS environmetal extensions, which COULD be HARMONIZER_TEMPLATES? nmdc-server#1238