Organize "specimen from organism" hierarchy by body system

[DanBerrios]

For example, integumentary system specimen, respiratory system specimen, etc.

[bpeters42]

To add some detail: We want to have the specimens listed in OBI to reflect the known anatomical relationships as they are encoded in Uberon, such as that nasopharynx is part of the respiratory system, and hence a nasopharynx specimen is a respiratory system specimen.

James points out that pulling in all of Uberon to make these inferences would massively grow OBI. In an impractical way. How else can we get this to happen? Manual assertions? Stop using ONTOFOX for import and use ROBOT instead?

[sebastianduesing]

I've been tinkering with our Uberon import to try to figure out a practical way to organize the anatomical entity hierarchy in OBI for the time being (that is, short of a full conversion away from OntoFox). I don't have a solution right now. I thought it may be useful to others/for future reference to give some more information on the problem, so this is a summary. TLDR: The automatic way to add hierarchy to the Uberon import nearly doubles the size of the import and produces a messy hierarchy, and the manual way is time-consuming, undesirable in principle, and dependent on Uberon terms that don't currently exist.

To ensure that OBI only pulls in the Uberon terms it strictly needs, OBI uses the "includeNoIntermediates" term retrieval setting in its OntoFox import. The resulting Uberon import module contains ~130 classes. This output is simple and minimal, but it is a close-to-flat hierarchy, so we have a long list of anatomical entities that are organized in no particular way.

It would be useful to have a relatively lightweight hierarchy, ideally organized by body system, so that we can apply that hierarchy to other branches that use anatomical entity terms (e.g., inferring that a lung specimen is a respiratory system specimen because a lung is a respiratory system part). This would require pulling in more Uberon terms.

The most automated way to do that would be to switch from "includeNoIntermediates" to "includeComputedIntermediates". However, doing so significantly increases the size of the Uberon import, taking it up to 237 classes, i.e., adding 107 classes that OBI is not currently using to support the 130 classes it does use. That's a pretty bad ratio. The resulting hierarchy is also neither elegant nor particularly useful:

This leads to our first problem.

Problem 1: The most effective way to add a useful hierarchy to OBI's Uberon OntoFox import is to do so manually. Simply adding a handful of useful upper-level terms is not enough. If we import a mid-level term like "organ", we get a bunch of classes that are asserted as subclasses of both "organ" and "material anatomical entity". If we want a cleaner hierarchy, we need to add lines in the OntoFox import file specifying intended subclass relationships of every term we want under "organ". We'd be more or less rewriting the whole hierarchy, which is bad in principle, not to mention laborious.

So the automatized method is unworkable and the manual method is undesirable. But there's a second problem here.

Problem 2: Uberon actually has very few dedicated grouping terms for all anatomical entities within a certain body system. Uberon's hierarchy leans heavily on "part of" relations; in OLS, for example, all terms for parts of various circulatory system structures show up under "circulatory system". This does not translate well through OntoFox, as our Uberon import drops all axioms except for simple subclass relations. We'd like to be able to assert that "middle nasal concha" has some relation to the respiratory system, so that "mid-turbinate nasal swab specimen" is a respiratory tract specimen, but obviously, we don't want to assert that "middle nasal concha" is a subclass of "respiratory system". We'd want it as a subclass of something like "respiratory system part" (or component, element, etc). But (unless they are very well hidden) it does not appear that Uberon actually has any such term. It does have "digestive system element", but this appears to be an exception to the rule, as by and large, most systems lack a dedicated term in this niche.

This problem is far from unsolvable; ostensibly, we could NTR a handful of useful "system element" terms. I include it here simply because it is a relevant complication.

[bpeters42]

Which of these problems would be solved by going away from OntoFox? If that is not clear, can we experiment on a branch that does this and look at the effect for specimen?

…

On Tue, Dec 3, 2024 at 12:08 PM Sebastian Duesing ***@***.***> wrote: I've been tinkering with our Uberon import to try to figure out a practical way to organize the anatomical entity hierarchy in OBI for the time being (that is, short of a full conversion away from OntoFox). I don't have a solution right now. I thought it may be useful to others/for future reference to give some more information on the problem, so this is a summary. *TLDR: The automatic way to add hierarchy to the Uberon import nearly doubles the size of the import and produces a messy hierarchy, and the manual way is time-consuming, undesirable in principle, and dependent on Uberon terms that don't currently exist.* To ensure that OBI only pulls in the Uberon terms it strictly needs, OBI uses the "includeNoIntermediates" term retrieval setting in its OntoFox import. The resulting Uberon import module contains ~130 classes. This output is simple and minimal, but it is a close-to-flat hierarchy, so we have a long list of anatomical entities that are organized in no particular way. It would be useful to have a relatively lightweight hierarchy, ideally organized by body system, so that we can apply that hierarchy to other branches that use anatomical entity terms (e.g., inferring that a lung specimen is a respiratory system specimen because a lung is a respiratory system part). This would require pulling in more Uberon terms. The most automated way to do that would be to switch from "includeNoIntermediates" to "includeComputedIntermediates". However, doing so *significantly* increases the size of the Uberon import, taking it up to 237 classes, *i.e.*, adding 107 classes that OBI is not currently using to support the 130 classes it does use. That's a pretty bad ratio. The resulting hierarchy is also neither elegant nor particularly useful: Screenshot.2024-12-03.at.1.12.59.PM.png (view on web) <https://github.com/user-attachments/assets/ec8ea890-c5b6-4999-bc24-df9ff0c4cacf> This leads to our first problem. *Problem 1: The most effective way to add a useful hierarchy to OBI's Uberon OntoFox import is to do so manually.* Simply adding a handful of useful upper-level terms is not enough. If we import a mid-level term like "organ", we get a bunch of classes that are asserted as subclasses of both "organ" and "material anatomical entity". If we want a cleaner hierarchy, we need to add lines in the OntoFox import file specifying intended subclass relationships of every term we want under "organ". We'd be more or less rewriting the whole hierarchy, which is bad in principle, not to mention laborious. So the automatized method is unworkable and the manual method is undesirable. But there's a second problem here. *Problem 2: Uberon actually has very few dedicated grouping terms for all anatomical entities within a certain body system.* Uberon's hierarchy leans heavily on "part of" relations; in OLS, for example, all terms for parts of various circulatory system structures show up under "circulatory system". This does not translate well through OntoFox, as our Uberon import drops all axioms except for simple subclass relations. We'd like to be able to assert that "middle nasal concha" has some relation to the respiratory system, so that "mid-turbinate nasal swab specimen" is a respiratory tract specimen, but obviously, we don't want to assert that "middle nasal concha" is a subclass of "respiratory system". We'd want it as a subclass of something like "respiratory system part" (or component, element, etc). But (unless they are *very* well hidden) it does not appear that Uberon actually has any such term. It does have "digestive system element", but this appears to be an exception to the rule, as by and large, most systems lack a dedicated term in this niche. This problem is far from unsolvable; ostensibly, we could NTR a handful of useful "system element" terms. I include it here simply because it is a relevant complication. — Reply to this email directly, view it on GitHub <#1833 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADJX2ITMDXHPDH72QXFFNCD2DYFVNAVCNFSM6AAAAABQX2F4R2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMJVGQ2TAOBVGE> . You are receiving this because you commented.Message ID: ***@***.***>

-- Bjoern Peters Professor La Jolla Institute for Immunology 9420 Athena Circle La Jolla, CA 92037, USA Tel: 858/752-6914 Fax: 858/752-6987 http://www.liai.org/pages/faculty-peters

[sebastianduesing]

I don't know enough about the alternative(s) (presumably an ODK import template?) to say with confidence that moving away from OntoFox would solve any part of this, but I am fairly certain that significant parts of this problem will exist no matter how we do our imports. It's my understanding that we would basically need to override much of Uberon's hierarchy/axiomatization to create a non-bulky hierarchy within OBI; we're dealing with the question of the extent to which we're willing/able/allowed to do that sort of hierarchy manipulation, which I know is a longstanding, broad issue within OBO, but it's also an issue that's completely independent of OntoFox vs ODK.

That being said, if we decide we're willing/able/allowed to force a simple, useful-for-OBI hierarchy onto the Uberon terms we import, I suspect that would probably be easier to do with ODK than with OntoFox. As to how that weighs against the costs of doing the OntoFox to ODK conversion, I don't know enough to say.

[jamesaoverton]

@sebastianduesing I disagree with some of your framing here.

We're currently using the MIREOT strategy for all our OBI imports. We're really just selecting a subset of the subClassOf axioms from the source ontology. Even when our OntoFox configuration files have a lot of manual fiddling, all those axioms should be true in the source ontology. The only exceptions are integration problems, like the ones we're trying to solve with COB. If we say something that the source ontology does not say about their terms, then we're in the wrong.

So everything we say in OBI about the source ontology will be something that the source ontology itself says or logically implies. We just don't say everything that they say. Words like "override" and "manipulate" are not appropriate. This is "pruning".

MIREOT is limited to simple subClassOf axioms. The issue here is about importing a wider variety of axioms, such as 'part of' restrictions, which means changing the import strategy from MIREOT to SLME or something else that understands OWL. That means using OWLAPI, which means using robot extract http://robot.obolibrary.org/extract. OBI already uses ROBOT for most things. ODK uses ROBOT for most things. Whether or not OBI adopts ODK isn't relevant here: we'll need a custom ROBOT command either way. The custom ROBOT command will have to balance a manual choice of Uberon classes with rules to select the axioms we want.

Yes, we can and should make a branch to try replacing OntoFox imports with ROBOT imports. Uberon might be one of the harder cases to start with, but maybe that's a good thing.

[sebastianduesing]

That's fair. In hindsight, "override"/"manipulate" sound a lot more charged than I intended—sorry about that. I'm with you on the fact that anything we'd be asserting would be taken directly from the source ontology; we're not injecting anything new. I think my core concern (which I did a fairly poor job of expressing) is about how much pruning an ontology ought to do. Ostensibly, there's nothing wrong with using a source ontology's full axiomatization of a term, and using only subClassOf axioms is a standard practice. So the two ends of the continuum are both reasonable, but I'm wary of the grey area of selectively importing certain axioms; that strikes me as more potentially troublesome than either taking all or taking none. That concern may just be a product of insufficient understanding on my part, as I can't really back up why I'm wary of that, except that it may make accidental term misuse easier down the line.

Thanks for the context on MIREOT vs SLME. I was definitely missing some information there. And I completely overlooked the fact that we could adopt ROBOT imports without adopting ODK. Regardless of my concern about selectively importing axioms, I agree that it's worth trying to adopt ROBOT imports.