Set up BFO import

[pbuttigieg]

Could we add BFO 2.0 to our /imports directory and as part of the make process? I'd like to use some more BFO classes, but I'm concerned that adding it may cause issues with existing classes and assertions (e.g. system being a subclass of material entity; incidentally, the PURL for system yields a 404).

[cmungall]

Note we already bring in BFO2 classes (the obo purl .../obo/bfo automatically references this), the RO purl for the system class (which should migrate to BFO2 eventually) should hopefully resolve next time ontobee does a load.

What needs to be done can be split into two chunks:

1. ENVO should add bridge axioms for native ENVO classes (Pier proposed omitting "environmental X" altogether and directly using "X" but I suggested leaving in for now as an intermediate step)
2. Use bridge axioms for ontology O to connect roots from O to BFO

The problem with 2 is that it's rarely done (I say that as maintainer of some of those Os, it hasn't been a priority)

CHEBI

'chemical entity' can subclass 'material entity' for now. @jannahastings the bfo bridge on the chebi ftp site is still for the ancient ifomis ontology. It would be great to have a central place (preferably github) that chebi controls for the bridge, but for now we may bridge directly in envo

pato

The ongoing issue here is qualities of processes. Formally pato:quality commits to some kind of union of BFO classes which is perfectly logical but won't lead to a clean looking hierarchy in protege

anatomical entity

I'll take care of this

admin regions

Do we know why these hang out at root? we just forgot about them?

craniofacial suture

looks like a SLME error

collection of organisms

@rlwalls2008 I believe PCO has the bridge axiom but we may be bringing in only the basic subset to avoid autophagy, I will investigate

[pbuttigieg]

admin regions
Do we know why these hang out at root? we just forgot about them?

I think there's some uncertainty on their placement - they're not necessarily material, but more like BFO:site relativised by some collection of fiat boundaries (borders) which may or may not coincide with physical entities. The same can be said for ecozones and ecoregions - although they are also treated as environmental systems.

It's likely I moved them out of geographic feature during my crusade to depopulate the not-so-meaningful "X feature" classes.

Once we have BFO:site available, we can provisionally place them to show our current thinking on the issue. I don't think users will really be concerned with this early on and we can make move them pending further discussion.

[pbuttigieg]

That still doesn't explain why they're scattered about. Will at least group administrative regions.

[cmungall]

Let's check we're seeing the same thing:

[pbuttigieg]

Yes - the offending administrative regions have now been grouped under administrative region in b704288
Since that commit however, Jenkins has build issues which relate to envo-simple.obo.

[pbuttigieg]

@cmungall Regarding 30e1d95 and
e8dc820, why would we add BFO classes to the RO seed rather than creating a BFO seed?

[cmungall]

RO already mireots the necessary classes from BFO. But we can add a separate BFO one as soon as the 2.0 classes release is out