search

OBOFoundry / COB

An experimental ontology containing key terms from Open Biological and Biomedical Ontologies (OBO)
https://obofoundry.github.io/COB
Creative Commons Zero v1.0 Universal
39 stars 8 forks source link

Proposed SOP: all NTR PRs where there exists at least one equivalent in OBO should be accompanied by a change in cob-to-external #238

Open cmungall opened 1 year ago

cmungall commented 1 year ago

See for example:

We should always include a corresponding mapping so that the intent and and history trail is completely clear, transparent, and computable, rather than there being a tacit agreement that the NTR is intended as a replacement.

Note that with the current pipeline the downside here is that this makes it harder for the ontology hosting the replaced term to replace with COB because the mapping signifies an override to a COB ID. This is because we are overloading cob-to-external with two goals.

We should separate out the goal of overriding a COB by either:

  1. using a different relation in cob-to-external (e.g. inverse of IAO:replaced_by)
  2. including an addition metadata file that indicates which COB IDs should not be overridden

I prefer the latter, it's the clearest separation of concerns

bpeters42 commented 1 year ago

Great points. As @ddooley pointed out in the other thread, the reason why OBI thought it is not correct to do a 1:1 mapping is that the COB term will be more general than the OBI one which was restricted to devices used in biomedical investigations. For COB, that distinction is stupid, because many devices are multi-purpose (e.g. a thermometer). And OBI doesn't mind loosing its 'device' class, and rather directly subclass the COB:device class.

So I think the issue with this term is different: OBI is proposing a multi-step change, where first COB:device is introduced, then OBI:device is obsoleted, and then all current OBI:device subclasses are assigned as their new parent COB:device.

If we want to always want to have a relationship of each COB term to its originating term, we can instead create 'general device' in OBI first, and then use that is the term mapping for COB:device. That would provide the 'history trail' that Chris is asking for. But it is a bit of a history rewrite...

I am not clear about the practical implications of all of this, and @cmungall and others should weigh in.

alanruttenberg commented 1 year ago

I'd characterize the steps a little differently, in the interest of not triggering the appearance that change in meaning is sanctioned ("we replace obi:device with cob:device")

  1. cob:device is introduced.
  2. cob:device is interposed as a superclass of obi:device
  3. obi:device is deprecated

This, coupled with an understanding that removing a parent class of a term does not invalidate the meaning of terms below it, and that in the case of a deprecation of a term, immediate children are to be asserted to be of the next most general class.

It's admittedly a subtle change, but it's one that seems more principled and actionable more generally.

That said, why bother deprecating obi:device - I don't see a particularly good reason to do so. It still refers perfectly fine. So do (1) and (2) and stop. Educate that a user might consider only querying against the more general device class as they see fit. To me, this seems the path of least churn.

The observation about thermometer might be applied not by wielding the hammer: all uses of obi:device become, effectively cob:device. Instead have uses of obi:device for cases of things like thermometer fixed by changing its asserted parent to cob:device. That's a change that would would make the term more closely match the intended meaning, something we regularly do.

Another reason to not to obsolete obi:device. Some users might have wanted that to be the parent of that term and disappearing it disruptive to them.

bpeters42 commented 1 year ago

The steps as described by @alanruttenberg is what I was intended to say but didn't - thanks for the clarification.

The reason for step 3 is that once we have cob:device in place, arguing what needs to go under obi:device vs. cob:device will be controverial/undecidable in many cases. What makes a device something that is solely intended to be used in an investigation? The manufacturer? And I doubt that would be a valuable distinction for the user community. Most importantly, OBI currently has plenty of classes under 'device' that are incorrectly placed there. 'catheter' for example is not a device that is only used in a scientific investigation,. This wasn't a problem in a world where OBI is used in isolation and only for for scientific investigations, but with the goal of re-using terms of OBI in a broader context, removing this distinction will make existing OBI terms more useful.