search

geneontology / minerva

BSD 3-Clause "New" or "Revised" License
6 stars 8 forks source link

Development annotations are in the Production GPAD #82

Closed ukemi closed 7 years ago

ukemi commented 7 years ago

We noticed that this annotation

MGI MGI:1915512 enables GO:0042171 PMID:26417903|gomodel:57c82fad00000358 ECO:0000314 20160916 GO_Noctua RO:0002413(GO:0004605),occurs_in(EMAPA:16894) lego-model-id=gomodel:57c82fad00000358|contributor=http://orcid.org/0000-0001-7476-6306

is in the production GPAD that is being created for mouse annotations.

This model is labeled 'development'. Annotations from models labeled as 'development' should never be in the production files.

balhoff commented 7 years ago

There is definitely a bug somewhere here, because if you download the OWL for the model, it says "production." I am guessing it is somehow related to the OWL API problem we had before with reading the production annotation from files. I expect the same problem will occur reading from the database and it will be a bit nondeterministic. The bug in OWL API was fixed a couple of days ago; I will look into how soon it will be released.

ukemi commented 7 years ago

Thanks Jim. I wonder if this is also related to #81. In that case the model is labeled as "production", but the annotations are not in the GPAD file.

ukemi commented 7 years ago

Hi Jim. I just went in and re-saved this model as "development" again. I downloaded the owl and I see the "development" state URI at the top of the file, but I still see "production" further down as the state value. In general, all models should be by default "development". It should be a conscious decision to make them "production" and we should be able to promote and deprecate them.

balhoff commented 7 years ago

I see the two values. I don't know how the production value was added. It seems like someone set it at some point, but then it was not read back into the application correctly. I am working on getting the OWL API fix into Minerva ASAP; I think this is a serious problem.

ukemi commented 7 years ago

Yes, it is. We don't want to load 'bad' annotations into the database. Let me know if you need anything else on my end. I am making a new model this afternoon. If you'd like, we can play around with changing it's state and see what happens.

ukemi commented 7 years ago

If you look at the Noctua home page, it list two states.

kltm commented 7 years ago

Noting that PR #83 includes an extra build step for minerva that requires a not-generally-available OWLAPI version.

kltm commented 7 years ago

@balhoff My intent on this is to follow the instructions, but instead of merging at this point, include the triple-order-fix branch build as the minerva-cli.jar in noctua. Is there a specific model that I should check against that we should use as a benchmark for the success of this process?

kltm commented 7 years ago

Also, is the suggested way to revert to the public version of the owlapi (when the time comes) to nuke ~/.m2/repository/owlapi/ ?

balhoff commented 7 years ago

No, I will just update the dependency in pom.xml for Minerva to point to the version of the new release.

kltm commented 7 years ago

Okay, so I'll just rebuild once the new fix is in--no need to recompile owltools, etc.

Do you have a test comparison so I can check before pushing the branch build of minerva onto the noctua master?

balhoff commented 7 years ago

Do you mean a model to check whether it is being read correctly? I don't have a good example. Some, like http://noctua.berkeleybop.org/editor/graph/gomodel:57c82fad00000358 are showing two values for model status (this needs to be fixed manually after this minerva is deployed). But there may be more that are hidden by this bug. Whether all values are seen depends on the order the triples are queried out of the database.

kltm commented 7 years ago

It's more that I want to confirm that I got the compilation steps right in the package that I'll copy into noctua master. I just tried, with the new minerva-cli.jar to run what I think should be the same thing:

java -jar ../noctua/java/lib/minerva-cli.jar http://purl.obolibrary.org/obo/go/extensions/go-lego.owl --reasoner elk --lego-to-gpad --group-by-model-organisms -i models/models --gpad-output /tmp/legacy/gpad --gaf-output /tmp/legacy/gaf

(This is my take on what the Jenkins job is doing, but as there is no minerva-cli.sh in the repo, I'm not sure how this is running at all; maybe @cmungall rememers?) However, it made no progress after almost two and a half hours on my machine, so I've given up trying to test locally or now...

balhoff commented 7 years ago

If you didn't compile and install the special OWL API correctly, the minerva build ought to fail, so you're probably alright.

balhoff commented 7 years ago

@ukemi we have deployed a new release of Noctua containing a fix for OWL API reading of model annotations. Could you please look through models at http://noctua.berkeleybop.org and verify correct development/production status? In particular, these have multiple statuses:

ukemi commented 7 years ago

Both of these were development. I have modified the models.

kltm commented 7 years ago

@ukemi The pipeline got backed up due to some unmerged upstream changes; I've now cleared these. Looking at the most recent pipeline product for production mgi, I cannot seem to find the rogue annotation

sjcarbon@moiraine:~/Downloads$:) grep "MGI:1915512" mgi.gaf 
sjcarbon@moiraine:~/Downloads$:)

Can you confirm (and close out if correct)?

balhoff commented 7 years ago

I will close this since it seems to be fixed. Please reopen or make a new ticket if there are further problems.