ols4
ols4 copied to clipboard
EBISPOT
Ubergraph
https://github.com/INCATools/ubergraph
Which parts of the functionality of ubergraph can we generalise and/or expose through OLS?
Can't just throw everything in OLS into the reasoner as would certainly be inconsistent and full of garbage. Maybe config option to specify lists of specific ontologies to turn into graphs and then a generalised API/UI over the top of them.
I would absolutely recommend against this. The ontology owners should supply the version of the ontology that they want the world to see, and there should be no reasoning, ubergraph or anything at all altering the structure of the ontology in graph form.
This would be a separate dataset. I’ll chat with you when I’m back from leave.
Just to jot some notes down from previous chats with @henrietteharmse
Currently OLS is backed by 2 Solr cores (1 for autocomplete, 1 for entity search) and 1 Neo4j graph.
We would like to enable more advanced DL-style queries over the OLS ontologies, which would be entirely separate from the core query functionality but accessible through the same API and UI. This would probably mean having some additional optional databases (perhaps e.g. a triplestore or another neo4j graph) which could maybe be populated using the same methods as ubergraph depending on how generalisable they are.
DL-style queries over the OLS ontologies
You can ask @dosumis who has been using https://owlery.docs.apiary.io/ in production in VFB pipeline - which may be one way, but not sure how performant that would be to load all of OLS. Probably not very.
Ubergraphs methods are entirely generalisable, we use it for all ontology as a proprocessing step in OAK (the main preprocessing is called "relation graph".
While an interesting avenue, I have had plenty of trouble with stuff like that in the past; I don't want to deter, just advice that approaching anything in this space will require significant resources (both developer and computational).
While an interesting avenue, I have had plenty of trouble with stuff like that in the past; I don't want to deter, just advice that approaching anything in this space will require significant resources (both developer and computational).
Absolutely - this is a research idea and perhaps we need a new issue label to separate it from things that can be immediately solved. Regardless the future potential of OLS is in exploiting the relationships captured by ontologies and exposing them as APIs; and currently ubergraph has that mindshare so it's exactly where we should be looking for inspiration.