remove foodon import

[cmungall]

We need to simplify our dependencies, in particular avoiding reciprocal dependencies, this is not good engineering practice. Also the more dependencies we have, the more fragile the system

Currently we use 2 foodon classes. Not sure we need to. If we remove we can remove the import and simplify, and avoid issues like https://github.com/FoodOntology/foodon/issues/106

The first use is 'mushroom' in 'mushroom environment'. I am not sure why we have mushroom environment. And why it is defined in terms of a food.

The other use is 'food material'. We have two subclasses, animal feed and plant feed

we have an interwoven envo->foodon->envo hierarchy:

(foodon is pink, envo white)

I don't think these kinds of reciprocal dependencies are good

[pbuttigieg]

The first use is 'mushroom' in 'mushroom environment'. I am not sure why we have mushroom environment. And why it is defined in terms of a food.

It's a valid environment, I don't see an issue with including it. It shouldn't be defined in terms of food, however. There's a term in BTO, but I'm not keen on importing that. Do we just remove the axioms?

animal feed and plant feed

We can move those to a different superclass - maybe organic material, leaving the food semantics to FOODON

[cmungall]

On Tue, Apr 13, 2021, 12:17 Pier Luigi Buttigieg @.***> wrote:

The first use is 'mushroom' in 'mushroom environment'. I am not sure why we have mushroom environment. And why it is defined in terms of a food.

It's a valid environment, I don't see an issue with including it. It shouldn't be defined in terms of food, however. There's a term in BTO http://purl.obolibrary.org/obo/BTO_0002167, but I'm not keen on importing that. Do we just remove the axioms?

How about renaming to basidiocarp Environment, keeping mushroom as related syn, and using FAO?

We could also try requesting mushroom from FAO

animal feed and plant feed

We can move those to a different superclass - maybe organic material, leaving the food semantics to FOODON

+1

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/EnvironmentOntology/envo/issues/945#issuecomment-818990542, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAMMOOZVPKSJTZD3U62BVDTISKEHANCNFSM4NALLSGA .

[cmungall]

Currently we are depending on a single foodon class:

SubClassOf(http://purl.obolibrary.org/obo/ENVO_02000047 http://purl.obolibrary.org/obo/FOODON_00002403) SubClassOf(http://purl.obolibrary.org/obo/ENVO_02000055 http://purl.obolibrary.org/obo/FOODON_00002403)

http://purl.obolibrary.org/obo/FOODON_00002403 (food material) is equivalent to environmental material and (has role some chebi:food)

so we can simply substitute and eliminate reciprocal dependencies and complex dependencies and interweaving such as the one above

[kaiiam]

Removing the foodon import should fix https://github.com/EnvironmentOntology/envo/issues/1216 correct as we would not longer have foodon terms. Perhaps these last two cases plant ENVO:02000055 and animal feed ENVO:02000047 might be better housed in foodon itself? @ddooley thoughts?

[ddooley]

Happy to take on animal and plant feed if that helps simplify.

BTW I don't quite understand the utility of the "fiat object / part" parent? I can't see how these objects are distinguished from many of the other ENVO material entity subclasses (objects that have passive or active mobility, i.e. constant or shifting stuff around their boundaries). Hope its not an old can I'm kicking!

[cmungall]

I am not aware of any use case for fiat object/part either. I think it could be removed with no loss of functionality or utility. Note it is currently not in COB so this branch of ENVO will show up as incompatible in future reports.

[kaiiam]

I also think it makes more sense for FOODON to take them as well as their children, ENVO:02000048 and ENVO:02000054. That way everything under the food material hierarchy is in FOODON. Then we can safely remove it all from ENVO. I don't think ENVO needs to be importing FOODON, (FOODON importing ENVO makes more sense).

Terms proposed to cede to FOODON:

ENVO:02000055
ENVO:02000047
ENVO:02000048
ENVO:02000054

Later perhaps food material or similar could be added to COB to root FOODON as we briefly discussed during the COB workshop.

[ddooley]

Let me know when there is ENVO consensus and I will make it so.

[cmungall]

Increasing the priority of this, we have a fail on master at the moment: #1240