-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Weird annotation assertion causes problems #78
Comments
The only usages of this axiom in PCO that I can find are coming in from IAO, GO, PATO, and ENVO. Are you suggesting that we remove the annotations from those imports before we do a release? That does not seem right. |
Can you tell me where you are seeing the problem in FlyBase, @matentzn? Maybe we used that property once without realizing it. |
Oh I never saw this in FlyBase.. It just causes some issues with importing PCO into other ontologies! Maybe it is solved when you refresh the imports? I just checked IAO and PATO and they both do not have this axiom in their most recent releases! |
Hmm. I just made new imports about a month ago, and they are still there. It's not IAO we import, but the full file for IAO metadata. I just opened the latest release (http://purl.obolibrary.org/obo/iao/ontology-metadata.owl) and there are many uses of that property. Same with PATO. What are the two of us doing differently? |
Also, we've never gotten a ROBOT error about that annotation property, but maybe you have custom checks set up. |
Ok, so first thing: This is a great mystery that I could not solve yet even after looking for a while. First of all: The annotation properties themselves are totally fine! Its the assertion
that is problematic. So instead of this (this is what it currently looks like):
It should look like:
You can see here for an example how it should be. So its really this Let me offer a hypothesis. |
Thanks for analyzing so carefully! You hypothesis is close. All of the imports are new, but I don't build them automatically with ODK. I use Robot, and then skip rebuilding them during release process. I do this to have more control over the import files, especially ENVO. I am working on integrating the import file builds into the releaseIn Robot, as I get better with make files. In Robot, I use the Let me play around with building the imports and see if I can get rid of it. If nothing else, I could remove it manually, although that is not ideal. |
Ahhh ok! This makes sense! Maybe avoid doing stuff manually.. I dont know whether |
Thanks again, Nico. I don't like to do anything manually either, but I don't use the defaults, and PCO is an old ontology - hard to script everything at this point. I suppose my hacking tolerance is quite a bit lower than yours! I just posted a question to obo discuss to try to figure out what the current consensus is on using defined by annotations with imports. |
Oops. Reopening until the issue is fixed. |
:P Oh god now you alerted the whole world to this issue.. Hahah. Ok... Lets I hope I leave the discussion with my head still attached! |
This annotation assertion in pco.owl causes some problems with ROBOT and profile validation:
I think this is because http://www.geneontology.org/formats/oboInOwl#created_by is built-in vocabulary of the OBO spec and you should not put any annotations on it! Could you remove it? And make sure that its not added as part of your release?
The text was updated successfully, but these errors were encountered: