Skip to content
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

Open
matentzn opened this issue Feb 20, 2020 · 11 comments
Open

Weird annotation assertion causes problems #78

matentzn opened this issue Feb 20, 2020 · 11 comments

Comments

@matentzn
Copy link

This annotation assertion in pco.owl causes some problems with ROBOT and profile validation:

<owl:AnnotationProperty rdf:about="http://www.geneontology.org/formats/oboInOwl#created_by">
        <rdfs:isDefinedBy rdf:resource="http://www.geneontology.org/formats/oboinowl.owl"/>
    </owl:AnnotationProperty>

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?

@ramonawalls
Copy link
Contributor

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.

@ramonawalls
Copy link
Contributor

Can you tell me where you are seeing the problem in FlyBase, @matentzn? Maybe we used that property once without realizing it.

@matentzn
Copy link
Author

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!

@ramonawalls
Copy link
Contributor

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?
Screen Shot 2020-02-26 at 4 32 22 PM
Screen Shot 2020-02-26 at 4 34 24 PM

@ramonawalls
Copy link
Contributor

Also, we've never gotten a ROBOT error about that annotation property, but maybe you have custom checks set up.

@matentzn
Copy link
Author

matentzn commented Feb 27, 2020

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

<rdfs:isDefinedBy rdf:resource="http://www.geneontology.org/formats/oboinowl.owl"/>

that is problematic. So instead of this (this is what it currently looks like):

<owl:AnnotationProperty rdf:about="http://www.geneontology.org/formats/oboInOwl#created_by">
        <rdfs:isDefinedBy rdf:resource="http://www.geneontology.org/formats/oboinowl.owl"/>
    </owl:AnnotationProperty>

It should look like:

<owl:AnnotationProperty rdf:about="http://www.geneontology.org/formats/oboInOwl#created_by" />

You can see here for an example how it should be.

So its really this rdf:isDefinedBy clause that is the problem, not the property itself (and unfortunately no ROBOT check will catch that).

Let me offer a hypothesis.
Before you migrated to ODK, you already had a few imports, especially go, ncbitaxon, envo and pato - the ones that have the problematic axiom. These seem to have not been refreshed by your new ODK setup (github says, they are more than 6 month old, while every other file you have is only 2 weeks old). Its this true? I also noticed that your ODK does not have ncbitaxon as a goal, so it will never be refreshed (hence the bad axiom will continue to linger. Do you thing I am thinking in the correct direction?

@ramonawalls
Copy link
Contributor

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 --annotate-with-source true option, which is what I think is adding that defined by annotation. I do want to include the defined by annotation for all the classes, and I don't currently know a way to remove it for just that property.

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.

@matentzn
Copy link
Author

Ahhh ok! This makes sense! Maybe avoid doing stuff manually.. I dont know whether --annotate-with-source is really worth it; You always have to remember that whatever stuff you add to your ontology, everyone downstream is adding as well - and maybe they dont want such annotations on all their classes - even if they are GO. This puts the burden on everyone else to remove such annotations again! Just my two cents.. I am pretty happy to hack around everything thrown my way, but maybe I am 1 of the 3 people in the world who like that.. :P Thanks for looking into it!

@ramonawalls
Copy link
Contributor

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.

@ramonawalls
Copy link
Contributor

Oops. Reopening until the issue is fixed.

@ramonawalls ramonawalls reopened this Feb 28, 2020
@matentzn
Copy link
Author

: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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants