You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
biolink does have a form of multiple inheritance, implemented as mixins, and has been moving more and more union classes into that. So for instance GeneOrGeneProduct is now a mixin instead of a class.
One nice thing about e.g. that one being a class is that you could query while being somewhat insulated against modling choices that some individual team made about whether to call something a gene or a gene product.
But with a mixin, that's hidden. The mixins aren't meant to be used by users. Do we want to use them anyway? If so, it makes the reasoner more complicated because now there's multiple inheritance in the system.
The text was updated successfully, but these errors were encountered:
Based on some later discussion, we do need to handle mixins to a degree. queries might show up with a mixin as an unbound node. This has been kind of a sticky problem because bmt hasn't allowed us to do descendents of mixins, but that is being fixed soon.
biolink does have a form of multiple inheritance, implemented as mixins, and has been moving more and more union classes into that. So for instance GeneOrGeneProduct is now a mixin instead of a class.
One nice thing about e.g. that one being a class is that you could query while being somewhat insulated against modling choices that some individual team made about whether to call something a gene or a gene product.
But with a mixin, that's hidden. The mixins aren't meant to be used by users. Do we want to use them anyway? If so, it makes the reasoner more complicated because now there's multiple inheritance in the system.
The text was updated successfully, but these errors were encountered: