Add RO import for COB integration

[sebastianduesing]

Adds ro_import.txt and ro_import.owl, which include eight relations that OBI currently uses but wouldn't be getting from COB after integration, as discussed with James:

• "has disposition" and "disposition of"
• "has function" and "function of"
• "has quality" and "quality of"
• "has member"
• "located in"

It appears that COB also doesn't include "has role" or "role of," which OBI also uses, though we didn't discuss importing that one—if that one's necessary as well, I'll add that in another commit.

[cmungall]

I'm likely missing a ton of context here, so my comments may be irrelevant.

I'm used to imports via robot/SLME, which is entailment-preserving. This of course can often end up bring in too much. Is there a way I can see what the underlying assumptions are, in terms of what axioms you intend to bring in and which you intend to exclude? Presumably there is an intention to exclude some otherwise you would use robot/SLME?

In particular, I note that you're not bringing in domain/range constraints. So currently in the context of OBI, located_in can be used between anything and anything.

I tested this by modifying an axiom in cell fixation to:

has_specified_input some 
    (cell
     and ('located in' some 'specimen collection process'))

Elk 0.5 classified the ontology as coherent (HermiT crashed protege).

I'm very interested in this. For ontologies such as go, uberon, cl, envo, D/R constraints are critical for QC. You can see this if you search any of these trackers for terms like "unsatisfiable". I am not making any judgments about methodology, I am just very interested in learning more about assumptions and methodologies in other ontologies. It seems for whatever reason D/R constraints are of less value in OBI? Maybe everyone editing it is superhuman and doesn't make mistakes? Or maybe there wasn't an intent to strip D/R in this case?

Relevant for: oborel/obo-relations#780

[bpeters42]

Discussed on OBI call 4/29:
You are right that the current import drops domains and ranges, and this is not what we plan to do longer term. Our problem is that we need to stepwise migrate over from our previous way of using solely RO-Core to now using COB with its relations, and NOT running into the issues of re-importing BFO classes that we don't want in domain / range axioms. We absolutely do want to change how we import RO relationships at a later time point, but we don't want to get stuck on everything being worked out in COB first. So we consider this a temporary fix that allows us to move forward with the COB integration. Hope that makes sense.

[jamesaoverton]

@sebastianduesing Let's create a cob branch and make this change there instead.

[cmungall]

Thanks!

[jamesaoverton]

Closing in favour of #1801.