Many cell types have a useless subclass to BFO:0000002 (continuant)

[cmungall]

E.g leukocyte: http://purl.obolibrary.org/obo/CL_0000738

in OAK:

Protege:

Explanation:

it's a complicated one but at the end of the day there are domain constraints that reference an above the shoreline BFO class. The fix is to remove axioms that reference above the shoreline or dangling classes (either) in the release product. Not sure if there is a standard ODK setup for this.

(of course base files remove all these issues, but browsers cannot use base files yet)

Note: before someone says that COB should fix this, COB won't fix it until this is decided on: oborel/obo-relations#780

[dosumis]

In the absence of a COB fix, we should just have a general CL fix, asserting cell to be a continuant. Redundancy stripping will then remove the inference on specific classes.

[addiehl]

I think cell should be asserted to be a 'material entity', arguably even an 'object'.

[dosumis]

Here's what we have:

The problem is that Uberon has no link up from material anatomical entity material entity:

We could simply fix that in Uberon and update imports. That would seem reasonable to me but if any opposition to that, I will just add an axiom directly on cell in CL.owl (as I don't want to inject axioms into Uberon.)

@cmungall - any preference?

Broader issue: We see lots of this type of thing on imports - stemming from not having BFO and relevant bridging axioms in the import chain. I'd really rather we cleaned it all up in the simplest possible way...

But not a priority I guess - just annoying and distracting for users.

[dosumis]

(Actually - it's worse than the screenshots imply as the release products just have bare BFO IRIs)

[dosumis]

I should have looked at Uberon more closely. It has:

The problem is with the ODK integrated import not pulling in the BFO mappings.

Chris' solution: The fix is to remove axioms that reference above the shoreline or dangling classes (either) in the release product. Not sure if there is a standard ODK setup for this.

@matentzn - is this possible? if removing dangling classes is something we can do as standard in ODK releases, I would do it for all release products apart from base (where dangling is the point).

My Q&D redundant solution: assert CL:cell to be a continuant. See PR.