Automatically add+expand nodes not in the KG

[dkoslicki]

This was something we had discussed previously: recognizing when a node is absent from the KG and then populating it automatically. For example, it would be nice to have "DOID:9849" in the KG, but it's not currently there. This would require making the KG not read only (which would be a risk) but the tradeoff is probably worth it.

[saramsey]

We sorta already do this, in a manner of speaking. BuildMasterKG.py loads multiple flat files containing lists of bioentities to seed in the KG. If any of these entities is already in the KG, it is not seeded. But if it is not already in the KG, it is seeded. So I think maybe you are just suggesting that we should make a more extensive file of bioentities to seed? If so, we can just add them to "data/q2/cop_data.tsv".

[saramsey]

Now that I read this more carefully, I think I see what you are asking. You want the Reasoning Engine to add nodes to the KG, is that right? How would the Reasoning Engine know which nodes to add?

[edeutsch]

sorry to butt into the conversation, but if the Reasoning Engine gets a question about a drug that's not in the KG, it seems like the ideal scenario is that the RE triggers the KGBuilder to seed and expand and then the RE can proceed with the question.. right?

[saramsey]

My “baby steps” approach: for the time being, I think it should simply add the drug to a file where we keep the “to-do” list of nodes to add. Then a cron job can regularly regenerate the KG with the additional nodes added, and flush the file (thus the file is acting as a to-do list).

…

----------------------------------------------------- Stephen Ramsey Assistant Professor, Oregon State University * School of Electrical Engineering and Computer Science * Department of Biomedical Sciences 208A Dryden Hall stephen.ramsey@oregonstate.edu<mailto:stephen.ramsey@oregonstate.edu> http://lab.saramsey.org On Mar 27, 2018, at 10:58 AM, Eric Deutsch <notifications@github.com<mailto:notifications@github.com>> wrote: sorry to butt into the conversation, but if the Reasoning Engine gets a question about a drug that's not in the KG, it seems like the ideal scenario is that the RE triggers the KGBuilder to seed and expand and then the RE can proceed with the question.. right? — You are receiving this because you commented. Reply to this email directly, view it on GitHub<#18 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AFTe-7mmFw1IqPl1rlVZpSJFmiB_ExHjks5tin3RgaJpZM4SjBQo>.

[edeutsch]

fine for baby steps. but I think that by or near the hackathon we should dream up a design by which the KG controller is an independent single thread agent that can read a queue of signals from multiple actors to seed and expand additional terms.

[saramsey]

OK

…

----------------------------------------------------- Stephen Ramsey Assistant Professor, Oregon State University * School of Electrical Engineering and Computer Science * Department of Biomedical Sciences 208A Dryden Hall stephen.ramsey@oregonstate.edu<mailto:stephen.ramsey@oregonstate.edu> http://lab.saramsey.org On Mar 27, 2018, at 11:05 AM, Eric Deutsch <notifications@github.com<mailto:notifications@github.com>> wrote: fine for baby steps. but I think that by or near the hackathon we should dream up a design by which the KG controller is an independent single thread agent that can read a queue of signals from multiple actors to seed and expand additional terms. — You are receiving this because you commented. Reply to this email directly, view it on GitHub<#18 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AFTe-5C0L_x2_28VGz2DLUqsufVQRms6ks5tin9sgaJpZM4SjBQo>.

[dkoslicki]

What Eric says is exactly what I was thinking. If the user asks for a COP for a drug that's not in the KG, it should add, 3X expand, and then reason as usual. I like the first approach Steve mentions, but it should be our goal to have it auto-add as this is the whole NCATS paradigm.

[dkoslicki]

Perhaps leverage the result of #48

[dkoslicki]

Closing due to #788