search

NCATS-Gamma / robokop-biolink-model

Schema and generated objects for biolink data model and upper ontology
0 stars 0 forks source link

General #1

Open stevencox opened 6 years ago

stevencox commented 6 years ago
cbizon commented 6 years ago

Do we want to propagate these to biolink-model? Wouldn't we rather go ahead and do the long term thing of fixing our stuff? With changing to the concept graph for planning instead of type-graph, I don't think that the .-notation is useful any more.

Related to https://github.com/NCATS-Gamma/robokop/issues/27

cbizon commented 6 years ago

On Genetic Condition, 2 points:

  1. There is also the question of Drug & Substance (where every Drug is-a Substance but not vice versa).
  2. We need to figure out for these kinds of relationships whether they live in the model as is-a or not.

Expanding on point 2 - I could imagine a couple of different approaches. First, we could add the subclasses and the relationships to the model. Second, we could treat them as attributes of an entity. That is, if you wanted to query for a genetic condition, it could either be done by having a genetic condition node type, or by doing a "where node.is_genetic_condition==True" or similar on a disease type.

Part of the decision may come down to whether we expect that services will want to use this node type to expose something. For instance - there are no services that we use that explicitly return "genetic conditions". They return diseases, and we check to see if we consider them genetic conditions on the client side. However, I think that the drug/substance case is one where particular services like pharos might make such a distinction.

stevencox commented 6 years ago

On the . notation thing, yes, it should be very short term. Also, if we go all the way now, all our queries break and we don't yet have concept annotated services or infrastructure to use them.