remove neo.owl from go-lego.owl used by minerva #260
Comments
|
@balhoff and @kltm could you take a look at this when you have time? See recent commit. I think it might be done.. I tested it with a local noctua that had go_lego loaded without the neo import and it worked as I wanted. Reasoner worked, the gene product parent types are added and saved for genes/proteins. Certainly some optimizations could be done, though it seems fast enough now. e.g. there are two requests to golr per incoming instance when there could be one. What else should I check on? Here is an example OWL file generated with this on. And screenshot. |
|
Discussed with @goodb after software call, with adjustments made to initial working list. There is probably more for conversation there, especially the final item concerning SynGO and how we want to treat exotic vs endemic models (e.g. categories as required add-in or not). |
…GOLR-#260 Conversion to neo lite and golr #260
Can run from the minerva command line as it sits. Most likely not useful code once we are done here. Could run it off a branch or merge it in and consider removing it later. or just leave it in.. not harmful. example from minerva-cli --update-gene-product-types -i /Users/bgood/Documents/GitHub/noctua-models/models/ -o /Users/bgood/test/typed_master/ -n /Users/bgood/gocam_ontology/neo_full_nov20_2019.owl -c /Users/bgood/gocam_ontology/catalog-no-import.xml
|
Changing first requirement here to a dynamic approach that never caches the rdf:type upper-type in the models that are displayed and saved, but only adds them as needed prior to reasoning. Was - - [ ] When a gene product instance is created in Noctua, add the high level rdf:type (protein or information biomacromolecule) from GOLR . Important that the main client interface does not see any changes as a result of this. |
|
@kltm when you are able, I would like to test #265 on dev. I believe it resolves our thanksgiving issue as well as reducing the number of other tasks on this issue list. If my local testing is reflective of dev and master server states, I think we are ready to tick down the rest of the checkboxes here. |
|
Slowed down with the Alliance meeting. Now on dev. |
|
I tested the UI on noctua-dev this morning with entries for several different species and entity types.
Note: will need to discuss validation errors based on entity types values, however. Various aspects of that discussion are already in multiple tickets on geneontology/go-shapes. |
|
Noting that the version @vanaukenk tested on |
|
@kltm although the mechanism evolved a bit, I think the task list on top remains accurate. |
goodb
changed the title
|
@goodb Okay, but my list there seems a little garbled to me now at this point, especially as I intended it to be ordered and I think we've accomplished some of these out of order already. It would be nice to go over this with you tomorrow either on the call or later on. |
|
@kltm trying to summarize "the plan" below. I think it takes three key files to make a system that will work for all the models in dev (and thus also master), including reactome, and will not pollute the global type-ahead system with reactome entities. Pipeline produces:
Services: |
|
@kltm if there were a way to filter GOLR requests to eliminate the reactome entities that would simplify things a bit (just add reacto to the import list that builds go-lego and no more need for -with-reacto everywhere). We would still need one OWL ontology that does not contain neo for minerva. |
|
@goodb Does this sound right to you? Current ontologies being made:
Current ontology journals (for minerva):
Ontologies we need:
Ontology journals we need (for minerva):
|
|
Assuming there isn't a way to deal with excluding reacto entities at the golr level, yes, this is it. |
|
@goodb Okay, what I'm trying to balance here is the simplest and least obscure product set with adding a set of required synchronized changes of client code (filtering reactome). Currently, we filter with Assuming we went the GOlr route, that would only save us the replacement of the journal above, correct? We'd still need some form of the other data products, right? It seems like as far as pipeline complexity goes, we save little. However, it does seem to make the products a little less stilted... |
|
I'm not really clear on what the regulates closure entails. CHEBI:23367 would include all of reacto as it stands. We could do a lot to tun it up to match a filter if we want as it isn't used for anything aside from these models. Given an uncertain future for reacto, I'd lean towards building the react-specific products rather the tuning up golr to avoid it for now. |
|
From the conversation on today's software call, let's go ahead and take the "data" approach, producing the specific data products needed (rather than trying to fudge the clients). Producing the products should probably occur on geneontology/pipeline, with the |
|
Related - pr to make reacto in the go makefile geneontology/go-ontology#19288. |
|
Closing. Only remaining thing to do is to get it running on master. believe that is its own issue. |
dev)devminerva to allow testingPer October 2019 discussions:
geneontology/neo#47
https://docs.google.com/document/d/1rOXCoJ-ZKGCGQ_0LpJOlsVVfVyKgUez52Kdq_VnUxEk/edit?ts=5d7ff0d8#
https://docs.google.com/document/d/1h_vnzkP94YC5l3ZmxKyZVOuTzIHIsHRsOLtBSGyB25k/edit?pli=1
In summary, we want to remove the dependency of loading classes from all gene products from all species into neo for access in minerva. This doesn't scale up very well. To accomplish this, the current plan is to move the class information (including label and main upper level type, e.g. protein, for gene product instances) out of neo and into GOLR alone. Minerva will then access this information dynamically as it builds and reasons over models.
The text was updated successfully, but these errors were encountered: