berkeley-schema-fy24 must migrate string "type" to object types consisting of the instances' class' `class_uri`

[turbomam]

The berkeley-schema-fy24 is much stricter about the type slot, compared to the current nmdc-schema

Currently the type of a WorkflowExecutionActivity is

An optional string that specifies the type object. This is used to allow for searches for different kinds of objects.

The berkeley-schema-fy24 requires that all data instances of nmdc-schema classes must reiterate the class' class_uri as a CURIe.

Theoretically there should be a good example of this pattern (for some WorkflowExecution) in the example data files directory already but I haven't found one yet.

cc @Michal-Babins @mslarae13

[eecavanna]

Thanks for bringing this to my attention, @turbomam.

Was there a specific PR for this change (the change to the type slot)? I think knowing its URL will help us (a) name the Migrator module and (b) get more info if we need it.

Is creating a CURIe something that involves obtaining something from the outside world (e.g. "minting" or "registering" something) or is it just a matter of combining various pieces of information that are already available in the same Mongo document? If it's the former (i.e. involves accessing the outside world), I may add something to the "adapter" class I'm currently working on, to support it.

---

Notes:

• Wikipedia page about CURIE

[turbomam]

Good questions.

This PR added the type slot to all classes:

• https://github.com/microbiomedata/berkeley-schema-fy24/pull/10
  • the new definition of type can be seen in that PR's src/schema/basic_slots.yaml
  • it also adds some test that check classes for their inclusion of the type slot

    This PR adds type values, in CURIe format, to all data instances in the example data files

• https://github.com/microbiomedata/berkeley-schema-fy24/pull/49
• nothing needs to be looked up externally to determine the appropriate type value for a data instance. The type value should just reiterate the class_uri of the class that has been instantiated. Maybe you can just determine that in Python code that by checking the types of each instance, including nested ones. But maybe you will need to open a SchemaView of the schema. Then you can look up SlotDefinitions by name and extract their class_uris.

from linkml_runtime import SchemaView
schema_yaml_file = "../src/schema/nmdc.yaml"
schema_view = SchemaView(schema_yaml_file)
study_class_obj = schema_view.get_class("CreditAssociation")
print(study_class_obj.class_uri)

prov:Association

_That one is unusual in the sense that the class_uri isn't equivalent to the default prefix (nmdc) followed by a colon and the class name. It's important to check_

I can help with this as much or little as you want.

[eecavanna]

Notes from 5/21/2024 migration squad meeting

• type slot in nmdc-schema has string range
• type slot in berkeley-schema-fy24 has to be a class_uri
  • uses the "designates type" meta slot (https://linkml.io/linkml-model/latest/docs/designates_type/)
  • rule: all classes must assert their class_uri
  • rule: all classes must be able to use the type slot (without reasserting that capability if they inherited that capability)
  • rule: all instances must assert their own type value

See: https://github.com/microbiomedata/berkeley-schema-fy24/tree/main/tests

• test_all_classes_assert_a_class_uri.py
• test_all_classes_can_use_type_slot.py
• test_inherited_slots_not_reiterated.py

[eecavanna]

Check whether https://github.com/microbiomedata/nmdc-schema/issues/1607 encapsulates this issue. See migrator nmdc_schema/migrators/migrator_from_X_to_PR10.py.

[aclum]

@turbomam can this be closed? I believe in berkeley all classes now have type required with a range of a curie.