EnvironmentOntology / envo

A community-driven ontology for the representation of environments
http://www.environmentontology.org
Creative Commons Zero v1.0 Universal
135 stars 52 forks source link

tundra, tundra biome, tundra ecosystem #787

Closed cmungall closed 4 years ago

cmungall commented 5 years ago

We have

image

With definitions:

A vegetated area which overlaps treeless, level, or gently rolling plains characteristic of arctic or subarctic regions, permanently frozen subsoil, and communities of low growing vegetation such as lichens, mosses, and stunted shrubs

An ecosystem which 1) typically has monthly average temperatures below 10 degrees Celsius 2) has a low evapotranspiration ratio and 3) is determined by communities of low-growing vegetation such as dwarf shrubs, sedges and grasses, mosses, and lichens.

A tundra is a terrestrial biome which includes, across its spatial extent, only low-growing vegetation such as dwarf shrubs, sedges and grasses, mosses, and lichens. Tundra biomes rarely have monthly average temperatures above 10 degrees Celsius and have low evapotranspiration ratios.

I don't think any of this is wrong per se, but I'm having some issues with underlying implicit design pattern

  1. I find it a bit unintuitive that tundra is_a .. is_a immaterial entity.
  2. I generally prefer to avoid shadow classes. Where we do have them we should make it very clear to annotators which to use in which contexts. E.g. we should have a microbiome subset that picks one of these.
  3. Where shadow classes are justified, I recommend picking one as the 'primary' through which the others are defined, and using a 1:1 relation. I also strongly recommend encoding the pattern as a dosdp yaml file. This will lead to easier maintenance and better internal consistency. Shadow classes where (a) there is no linking through OWL definitions and (b) any linking is via weak relations like partially overlaps constitute an anti-pattern.
  4. Additionally, shadow classes should mirror definitions as far as possible. It shouldn't look like each member of the triad was taken from a different source.
pbuttigieg commented 5 years ago

Thanks @cmungall - we do have to think about more predictable links between sites and material entities, but the definitions are often coming in from expert groups and we should also be cautious if changing them because of

I find it a bit unintuitive that tundra is_a .. is_a immaterial entity.

We can relabel to "area of tundra" if that makes things better

I generally prefer to avoid shadow classes. Where we do have them we should make it very clear to annotators which to use in which contexts. E.g. we should have a microbiome subset that picks one of these.

They're needed here for geospatial applications. We can can certainly add comments or editor notes suggesting usage best practices.

The microbiome subset should pick one of the MEs. I'd assume the biome may be more sensible for continuity.

Where shadow classes are justified, I recommend picking one as the 'primary' through which the others are defined, and using a 1:1 relation.

In this constellation (which is reasonably common if a biome class exists), the ecosystem class should be primary, as the other two depend on it.

I also strongly recommend encoding the pattern as a dosdp yaml file. This will lead to easier maintenance and better internal consistency. Shadow classes where (a) there is no linking through OWL definitions and (b) any linking is via weak relations like partially overlaps constitute an anti-pattern.

We could, but some of these will not be "easy" or consistent due to how experts in the relevant communities define these things. I'm not really keen on coming up with anything that doesn't align to that. However, if you have a suggestion for a pattern that will be robust to that, please do develop the idea here.

Additionally, shadow classes should mirror definitions as far as possible. It shouldn't look like each member of the triad was taken from a different source.

But some will be, and we can't form a consensus where none exists in the domain. @rduerr's GCW work is revealing quite a lot of these cases. This leads to a bigger issue on how we handle these conflicts while trying to keep some degree of consistency in the ontology. My feeling is to try to find the minimal overlap in the source definitions and make the ENVO classes reflect those. We can add more specific subclasses that map 1:1 with official definitions.

rduerr commented 5 years ago

But some will be, and we can't form a consensus where none exists in the domain. @rduerr's GCW work is revealing quite a lot of these cases. This leads to a bigger issue on how we handle these conflicts while trying to keep some degree of consistency in the ontology. My feeling is to try to find the minimal overlap in the source definitions and make the ENVO classes reflect those. We can add more specific subclasses that map 1:1 with official definitions.

This works for me as long as we can clearly differentiate in some way which communities use which subclasses....

pbuttigieg commented 5 years ago

During our Cryohackathon today, we noted: