Avoid injecting OBI subClassOf axioms

[cmungall]

There is emerging consensus that we should avoid subclass injection in OBO

there are two cases of this:

portion of material is generic and should go somewhere more general - maybe COB? But in this case it's odd, why is device a portion of material?

elution and extraction seem in scope for OBI

there are also other injections, e.g.

what are the scoping rules for CHMO vs OBI?

[ghost]

These concepts are well covered in the ISA-95 standard, I don't think there is a lot of value to create a different concept, the definition of an equipment would be best placed outside of the OBI and CHMO since it would apply in a factory as good as it applies in a lab so it more of an engineering topic and would be reused in CHMO and OBI

[batchelorc]

Happy to donate terms to OBI - is there anything specific I need to do?

[batchelorc]

... or make any clashes obsolete, of course.

[StroemPhi]

Happy to donate terms to OBI - is there anything specific I need to do?

Having read previous discussions around the problems with adopting external terms into ones namespace and assuming the CHMOs user base can handle the obsoletion & replacement of term IDs, I'd say the best way forward for elution, extraction and microwave oven would be:

1. to file a new term request for these in OBI
2. add a note on these in CHMO to warn about their upcomming obsoletion & replacement once the OBI NTRs have been merged
3. to document this change with rdfs:comments on the obsoleted CHMO as well as the newly minted OBI terms and in the release notes of the resulting new CHMO and OBI version

But also following the line of argumentation by critics of this approach, I'd say such a plan should be announced on the OBO-discuss list, to be save and allow feedback before hand.

Regarding "portion of material", from the provided definition I cannot see a clear destinction to BFO:"material entity" and would thus just obsolete it, but this is just me.

[StroemPhi]

Context to the depricate&mint vs. adoption discussion: https://github.com/OBOFoundry/OBOFoundry.github.io/issues/1676

[ghost]

I think the comments are good, is the OBI then considered to be the master source of all terms for all unit operations across the domains of chemistry, culinary, engineering domains?

[StroemPhi]

@TobyAutoChem I'm not sure I understand your question correctly. This is not about subclassing a leaf node from another ontology and thus extending it. This kind of insertion runs the risk of changing the semantics of the existing ontology (here OBI) and should rather be avoided if I understand the OBO principles right.

[ghost]

@StroemPhi I though you meant that it would be removed from one place e.g. CHMO and then this would reference the once in OBI as you say to avoid an extension since they are the same object?

[StroemPhi]

@TobyAutoChem yes for the terms referenced here. But not necessarily for "all unit operations across the domains of chemistry, culinary, engineering domains". I guess this needs to be discussed on a term by term basis with regard to the scope of OBI and other ontologies.

[ghost]

@StroemPhi Ah OK, yes fundamentally the control of temperature for example is used in many domains so it would be logical for me that is was not in the OBI but I'm not aware of the correct place for it to go, it should be more of an engineering ontology then domains of biology and chemisty,... could reference the core ontology.

[cmungall]

I agree with @StroemPhi's recommendations for the immediate resolution of this issue

I also take on board @TobyAutoChem's comments. Modularity is a big challenge in OBO. We have many ontologies whose domain is not strict biological (ENVO, CHEBI) and ontologies that have mid-upper levels that are general enough for many domains (OBI, IAO, OMRSE). But I think it's best to take these to either the OBO tracker or the respective tracker like OBI

[ghost]

We have a new project with some large Pharma companies to make another "Chemical Process" ontology, we can try to include things from other places