rethink is_a dh_interface requirement for including class in menu system?

[turbomam]

I think that LinkML schema classes aren't included in the template menu unless they is_a: dh_interface

is_a is single-valued, so reserving it for this purpose eliminates its usefulness for making real hierarchical statements about classes. We could switch to

mixins:

• dh_interface

but I think @cmungall may have something else in mind

cc @pkalita-lbl

[ddooley]

Ah, I see, is_a being single valued could be problematic visa vis inheritance etc.

d.

[ddooley]

LinkML has a "tree_root" marker that can be set explicitly (or is otherwise inferred within various LinkML interrogation methods as a class that doesn't show up in range of another slot). Is "tree_root" a better candidate rather than "dh_interface"?

[pkalita-lbl]

I think there's a decent argument to be made for using tree_root. Lots of other LinkML tools that need to look at a particular class within a schema will use tree_root as part of the process of identifying which class to look at. One word of caution though, I don't think it's strictly enforced in any way but I think most tools assume there is only one class in a schema with tree_root: true. See for example this utility method in the LinkML codebase: https://github.com/linkml/linkml/blob/2407a2f2c629092c15da6e0295600d895d34a465/linkml/utils/datautils.py#L69-L80

If sticking with the one-tree-root-per-schema convention works for you then I would encourage using that. If you need to mark multiple classes per schema as DH interfaces, then you might think about coming up with a convention that uses the annotations slot on class definitions.

[ddooley]

What we are seeing with the new DataHarmonizer 1-many data schema is that we need a "Container" class in a LinkML specification that lists all the Classes to show as tables involved, and their relationships as defined by primary keys. So we won't be needing dh_interface any more.