-
Notifications
You must be signed in to change notification settings - Fork 36
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
FOODON unsatisfiable classes killing ENVO build #42
Comments
Weirdly, we may still be pulling in an older version. I can't seem to find that class in foodon.owl either. Is it in an import? |
It may also be caused be FOODON now treating these classes as information artifacts, which has made some of ENVO's axioms break. See this line in the report. Checking this now. |
I was discussing with Pier and he is right. The problem comes from the fact that 'vertebrate animal food product' is defined as the intersection of several classes including 'food material', while being a subclass of 'information content entity'. As 'independant continuant' and 'generally dependant continuant' are disjoint, ENVO ends up being inconsistent. |
Thanks for tracking this down @marieALaporte! (if you get a chance can you paste in a screenshot of the Protege explanation - it's a nice demonstration of how we use reasoning and can help when others come onto a project. Not urgent though). First we need to get the right QC in place for foodon so these don't leak out in the first place. It looks like the imports don't include BFO and disjointness axioms. Second we need a workaround for ENVO. This may be only taking classes that are subclass of food product, and not doing the full SLME |
Thanks folks for analyzing this. I'll be able to dive into this in an hour and a half. I need to adjust "food product type" subclass of 'categorical tree specification' and the like. A temporary workaround would be not to import the 'categorical tree specification' class. So far this is unique to FoodOn/GenEpio. |
@Public-Health-Bioinformatics Many of the information-based subclasses have defs that read like those of material entities. In fact, I'd assume most FOODON users (including ENVO) would want to reference food rather than information about food. Would we have that possibility? |
What would really help is if FOODON can make a new release, and make a subset that is only subclasses of classes that don't inherit this. We can do this using robot in the envo pipeline but always better to have fixes upstream (or better, if it can be fixed altogether) |
The "categorical tree specification" class was something our ontology form builder software was using to find picklists of food products items to populate forms with, but I see that's not going to work as a direct class so I'll pop a relation in there between categorical tree specification and the material classes that describe foods. Sorry I didn't see that coming. |
@Public-Health-Bioinformatics many of the errors are of the kind:
The label should make it clear this is a value specification. If you can change them to something like this:
...I think they would be better. Note that food source is in the information hierarchies. It would have to be a material entity for this to work. It reads like it should be. You should take the NCBITaxon entry for these (or aggregates of taxa) and give then a
or precompose food source classes like: |
Ah, I see. Yes, causes turbulence. As noted above, most of these langual imports (e.g. food source) are referring to material things in their definitions. I'm not sure it's semantically sound to keep these in an IAO branch. |
I tried to separate out the foodon / LanguaL items that seemed strictly information content entity subclasses:
Anything else in FoodOn that ended up inferred as under IAO is an unintended inference at this point. |
So to fix "categorical tree specification" I would move to have "food product type", "food source" and "food treatment process" etc. all become "SubClassOf 'member of' some 'categorical tree specification'". This will stop them all from becoming IAO's. (Or I create a new relation for this, say "has specification type" if "member of" has too broad a collection semantic?) |
Ok, I've prepared a release which has the categorical tree spec. fix in it. In next few days I'll try integrating BFO top level axioms so I can at least spot BFO related reasoner issues. |
Is there a way to have OntoFox import the DisjointClasses axiom(s)? If not I guess I have to manually bring in the BFO owl file. |
Also I'm at a loss about why FoodOn isn't triggering a travis test. I've just upgraded robot, btw. |
this seems fine: |
Looks like it was triggered last master commit: https://travis-ci.org/FoodOntology/foodon Hmm, looks like travis cfg only for master.. this is a mistake in osk too |
Sounds PATO:quality-like
It still looks like it will be confusing and semantically (i.e. according to many of the definitions) iffy. If the def is about a process, it should be a process, not an information artifact. For any process "P", you can create an information artifact class "P specification" which is about that process (not sure of member of here) if needed (why is it needed?) Most of the others really sound like material entities.
You should be able to do this all with ROBOT and owltools.
@cmungall can probably spot that, it does seem you have a reasoning step here under the @cmungall is that were the errors should be thrown? It's in the reduce command, rather than the reason command as it is in ECOCORE , could that be an issue? |
But why would the errors slip by? |
If it's a member of a collection of classification specs, then it is itself a classification spec, so this doesn't help clean up the semantics, unfortunately. Also, classes like We get the following errors: Similar issue, you're treating information artifacts as if they're the actual processes or continuants. Here, because you treat a process as an information artifact, it ends up being a continuant rather than an occurent: This would all be solved if you move these classes to where their defs say they belong: actual processes or material entities. You can then create "specification" classes that are IAO:about them if you really need these to be IAs. |
Arg. I don't want any of the food product items or processes to be IAO's really! They already have a home under processes or material entities if you see their subClassOf axioms. I loaded all of BFO + axioms (via OntoFox) to test with reasoner but I see now I have to get RO axioms too. Doing that now. (At moment when I run ELK I don't get the above inference contradiction). I can see 'member of' some 'categorical tree specification' isn't going to work as it is a subclass of RO 'part of'. |
It appears OntoFox doesn't include disjointWith axioms in its output files (even if one requests all axioms). I had to download BFO directly to get them. I'll raise that with OntoFox. |
In summary, I'll drop using 'member of' some 'categorical tree specification' (or categorical value specification) due to the inheritance - looks like its the transitivity of 'part of' that is making this happen. The use of this 'categorical tree specification' class is not core to FoodOn, but rather is part of a small set of terms used by our GEEM tool for grappling on to a given ontology to create form/data structure specifications for displaying and allowing data entry of food sample features. I do want to enable the GEEM components to be married with a given ontology by way of an import file but also want this to be BFO compatible of course. The right relation doesn't seem to exist, so I think I'll have to make a new one. Whether this is can be an object relation or must be an annotation is a decision. |
A different problem has surfaced now with full BFO axiomatization. Chebi "Vitamin C" http://purl.obolibrary.org/obo/CHEBI_21241 is listed as a role while all the other vitamins are listed as chemical entities. This leads to a contradiction when placed in the same list. |
In GO we have a design pattern 'chemical entity' and has-role some |
e.g. |
Yes, I don't mind that - its just that all the other vitamins in CHEBI are chemical entities, so vitamin D, E etc. C is the only one that is a role. Maybe its a chemistry peculiarity. Seems like the others would have roles too - 1 step removed from chemical entity, but perhaps they are more 1-1 than C. Ascorbic acid is also in CHEBI, but has no synonym or other link to Vitamin C. |
raise it on their tracker!
…On 26 Apr 2018, at 19:38, Damion Dooley wrote:
Yes, I don't mind that - its just that all the other vitamins in CHEBI
are chemical entities, so vitamin D, E etc. C is the only one that is
a role!
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#42 (comment)
|
ok, BFO related contradictions I think are resolved in new release. Vitamin ticket submitted to CHEBI. |
We're here: https://travis-ci.org/EnvironmentOntology/envo/builds/371934486#L3073-L3090 Some equivalence axioms make some classes the same. You may as well merge them if you wish to keep the same equiv axiomatisation. |
Not sure you need them to throw these errors. These are coming from logic errors or class equivalencies.
Yes, you're mixing very different categories which don't follow the labels or definitions of the classes themselves. I don't think any of them should be information artifacts.
Sure, but activities like this shouldn't mess with the hierarchies so profoundly. As said above, if you need information artifact classes, make new classes that are linked to the bona fide entities.
Please explain the semantics of what exactly you're trying to do, we could probably figure it out. |
Hmm, I'll address those - but is there a robot command that yields those error situations that I can run command line? At moment I'm flying blind until it does testing at envo end. I can see the equivalencies now being stated in Protege when I run the ELK reasoner - but they're buried in the hierarchy so I won't be able to find them in the future until the test script is fixed/triggered in travis. About the Ontofox disjointWith - I wasn't getting any contradictions in Protege with ELK reasoner and FoodON because there were no BFO disjointWith axioms in BFO_import.owl which is produced as Ontofox output file. Ontofox folks are looking into whether disjointWith can be/should be included in their generated files. But swapping in original BFO.owl has fixed that. Indeed, GEEM shouldn't have any logical conflict with ontologies it connects to. Originally I thought multi-homing terms would be ok (the ability of an ontology entity to hold more than one semantic sense at a time) but I see clearly that disjointWith nixes parts of that approach. GEEM is all about creating data standard "wrappers" around ontology contents. I had approached this by using some object relations in the past, but have to switch one or two of these over to annotations to stop the impact on reasoning. I'll follow up more directly with you on the use cases there. |
Done new release, should fix above errors. |
Seems to have fixed our build 👍 Perhaps it's best to stick to asserting subclass axioms rather than equivalence axioms in the raw development phases? You'd still be able to query, but would avoid running into these errors. However, there are a few of orphan classes at the top level that may need cleanup (not breaking any builds though): Interestingly, the number of orphan classes seems to go up in the ENVO mirror of FOODON (@cmungall any thoughts here? Is this an import chain issue?): |
Ok, good. I've found that ELK doesn't catch all equivalency issues – so started also testing against Fact or Hermit too. Orphans are a result of an updated include file I forgot to position new items of. They'll go away next refresh. (I can't quite spot a pattern in list of orphans you have for envo mirror of foodon – seems like an item's parent class is missing here and there, yet its sibling isn't in orphan list). D. |
@Public-Health-Bioinformatics, Are you tagging these releases? The last one I see is from 2017. Good to have tracking here.
I'm still curious about why this isn't running in your build routine. Do you need a
Great, thanks. ETA? We don't strictly need this for the release but I'd like to refresh ENVO once that's done.
It's a bit occult right now. Will let you know if we find out more. |
About release tagging, I was hesitating to stamp a new one until a smaller backlog of SIREN food products are positioned. But I can mint a release regardless if you like. In addition the version id of foodon does change (weekly if not daily), it states the publishing day. |
I've just made a 0.4 alpha pre-release. |
Hi @Public-Health-Bioinformatics
seems the hydra won't die so easily:
https://travis-ci.org/EnvironmentOntology/envo/jobs/371051125#L2137-L2460
@cmungall I've updated robot and re-imported FOODON, but still get these errors.
It also seems that FOODON's build checking routine is still not actually testing anything as far as reasoning goes:
https://travis-ci.org/FoodOntology/foodon
The text was updated successfully, but these errors were encountered: