Upgrading FoodOn to work with COB as top-level

[ddooley]

I thought I'd report out about the FoodOn conversion to COB. The main effort is to adapt all the existing MIREOT term importing from other sources to not use BFO upper level. At moment FoodOn build is still working with OntoFox which enables us to stop the import of a term's ancestors past a certain parent, so it works well in giving the list of COB top level terms, and thereby not have to retrieve BFO upper level terms even though they are situated under them often.

A few things do come up:

COB's erroneous "material entity" id will be taken care of soon I see.

UBERON and CARO have this thing called "biological entity". Does that fit in COB? Or do I place their subClass "anatomical entity" under "material entity" directly?

UBERON has "life cycle". Do we fudge that into "process"?

I'm bringing OWLTime in to cover describing durations of processes. Where can I place time:Duration? I had brought in "one-dimensional temporal region" as a parent from BFO, but where would that fit?

Thanks for advice,

Damion

[matentzn]

@ddooley thank you for taking the time to write this! I don't know any of the answers, but I want to give a big thumbs up for the work you have been doing integrating COB and identifying issues!

[cmungall]

• CARO is going away. See #244 and https://github.com/obophenotype/uberon/issues/2349
• Life stages is still unresolved: See #40
• duration is a characteristic. PATO:0001309 ! duration. See https://github.com/oborel/obo-relations/pull/284 for context on QoPs

[ddooley]

Ok, update is FoodOn has

• eliminated all CARO references;
• We await life stage resolution;
• the time:Duration we are intending to use comes with all the data properties necessary to describe duration in a number of convenient ways. Agree that duration in OBO Foundry is a process characteristic. But using OWL_Time conveniently, it would be great if BFO/COB:process could be a mixin subclass of time:properInterval (subclass of time:TemporalEntity). As it is we have to use an extra time:hasTime object property that seems logically redundant: