NTR: organism part derivative

Question

NTR: organism part derivative

Opened this issue 2 years ago · 8 comments

We want a place for classes for:

a butchered cow heart
a heart in the middle of transplantation

These should not be subclasses of uberon heart as this will be unsatisfiable (uberon:heart SubClassOf part-of some organism, contained-in some thoracic cavity, etc)

one option is to branch within the AO:

COB:material anatomical entity = Uberon:material anatomical entity
- extra-organismal derivative
  - extracted heart (sub: derived-from some Uberon:heart)
- Uberon:organ [unique label: "in-organism canonical organ"]
  - Uberon:heart [unique label: "in-organism canonical heart"]

(CL essentially does this with cell/native cell split)

another is to branch outside the AO

COB:material anatomical entity = Uberon:material anatomical entity [unique label: "in-organism canonical material entity"]
- Uberon:organ [unique label: "in-organism canonical organ"]
  - Uberon:heart [unique label: "in-organism canonical heart"]
COB:extra-organismal derived anatomical entity
- extracted heart (sub: derived-from some Uberon:heart)

Answer 1 · 2022-05-23T18:39:03.000Z

We have these under 'processed specimen' in OBI.

…

On Mon, May 23, 2022 at 10:23 AM Chris Mungall ***@***.***> wrote: Context: obophenotype/uberon#2427 <obophenotype/uberon#2427> We want a place for classes for: - a butchered cow heart - a heart in the middle of transplantation These should not be subclasses of uberon heart as this will be unsatisfiable (uberon:heart SubClassOf part-of some organism, contained-in some thoracic cavity, etc) one option is to branch within the AO: - COB:material anatomical entity = Uberon:material anatomical entity - extra-organismal derivative - extracted heart (sub: derived-from some Uberon:heart) - Uberon:organ [unique label: "in-organism canonical organ"] - Uberon:heart [unique label: "in-organism canonical heart"] (CL essentially does this with cell/native cell split) another is to branch outside the AO - COB:material anatomical entity = Uberon:material anatomical entity [unique label: "in-organism canonical material entity"] - Uberon:organ [unique label: "in-organism canonical organ"] - Uberon:heart [unique label: "in-organism canonical heart"] - COB:extra-organismal derived anatomical entity - extracted heart (sub: derived-from some Uberon:heart) — Reply to this email directly, view it on GitHub <#204>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADJX2IT3FBRN4ZIPCMGTP33VLO5HJANCNFSM5WWRKBDQ> . You are receiving this because you are subscribed to this thread.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

Answer 2 · 2022-05-23T19:08:00.000Z

@bpeters42 You mean you would paradigm-fit those under 'processed specimen'? I'm not seeing existing equivalents there for whole organs (or plant parts, FoodOn's need). Also maybe 'specimen' would be technically a better OBI parent to consider? Nothing is necessarily done to organ after it becomes a "specimen" via extraction, so not nec. processed. "Specimen" seems a bit semantically loaded towards technical analysis use though. An "extracted material" parent class would avoid such assumptions up-front?

Answer 3 · 2022-05-23T20:52:06.000Z

Damion: I was trying to reply quickly, and was not thorough. I saw: "butchered heart" and "extracted heart" which would very much fall under 'processed specimen'. We have had a lot of discussion of what makes something 'processed', especially if the point of the process is to keep things in their native state. And while 'butchered' is clearly less conservative than other modes of processing, I am pretty sure that every anatomist would consider a heart lying on a table to be different from a heart inside of an animal, no matter how carefully the process of extraction was. But yes, we can also put these under 'heart specimen'. It would be great to have the OBI design patterns for no-longer-anatomical-entities agreed on or approved upon within COB. - Bjoern

…

On Mon, May 23, 2022 at 12:08 PM Damion Dooley ***@***.***> wrote: @bpeters42 <https://github.com/bpeters42> You mean you would paradigm-fit those under 'processed specimen'? I'm not seeing existing equivalents there for whole organs (or plant parts, FoodOn's need). Also maybe 'specimen' would be technically a better OBI parent to consider? Nothing is necessarily done to organ after it becomes a "specimen" via extraction, so not nec. processed. "Specimen" seems a bit semantically loaded towards technical analysis use though. An "extracted material" parent class would avoid such assumptions up-front? — Reply to this email directly, view it on GitHub <#204 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADJX2IXTNILTRWKQLDF5DWLVLPJR3ANCNFSM5WWRKBDQ> . You are receiving this because you were mentioned.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

Answer 4 · 2023-03-31T03:40:39.000Z

I just realized there is likely a formal problem in defining a new entity "extracted heart", severed from its bodily context, and then trying to refer to one of its parts.

_:HT1
typeOf 'extracted heart'
_:LV1
typeOf 'left ventricle instance'
'part of' _:HT1

If we refer to LV1 directly, UBERON implies in-situ connection to rest of a canonical body.
Say instead of _:LV1 we tried instead to refer to an "extracted heart left ventricle" _:EHLV2. That doesn't work because it is not extracted from the heart it is in?

Answer 5 · 2023-03-31T14:25:17.000Z

_LV1 is not a 'left ventricle instance' but a 'processed specimen' that is part_of extracted heart, and derived from left ventricle instance.

…

On Thu, Mar 30, 2023 at 8:40 PM Damion Dooley ***@***.***> wrote: I just realized there is likely a formal problem in defining a new entity "extracted heart", severed from its bodily context, and then trying to refer to one of its parts. _:HT1 typeOf 'extracted heart' _:LV1 typeOf 'left ventricle instance' 'part of' _:HT1 If we refer to LV1 directly, UBERON implies in-situ connection to rest of a canonical body. Say we tried instead to refer to an "extracted heart left ventricle" EHLV2. That doesn't work because it is not extracted from the heart it is in? — Reply to this email directly, view it on GitHub <#204 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADJX2IT6ZIWA5TGFVDNUVQDW6ZG4FANCNFSM5WWRKBDQ> . You are receiving this because you were mentioned.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

Answer 6 · 2023-03-31T14:59:29.000Z

My point was that all the parthood that one would like to rely upon somehow with UBERON, i.e. just knowing that the heart specimen I have before me has a 'left ventricle instance' and therefore I should see it connected to such and such, can't be taken advantage of. One has to re-create a whole mirrored parthood. Every part of the heart before me has to be declared a processed specimen itself, and all the parthood connections between them declaired at the instance level? Maybe that's something I didn't realize about instance-level entities that are not in-situ instances of anatomical classes.

Answer 7 · 2023-03-31T15:12:05.000Z

We certainly should not recreate an entire hierarchy, and I dont' think we have to, if we get the property chain right. If 'processed heart' is derived from 'heart' than part_of 'processed heart' should be inferreable as derived from part_of 'heart'. So for example, we should be able to find a problem of X is a processed specimen derived from some liver, and X is part_of processed heart. Not saying that works flawlessly now, just that is what we should strive for. And obviously there can be a processed specimen that intermixes heart and liver cells for example - but it would not longer have a derived from relationship to a single organ.

…

On Fri, Mar 31, 2023 at 7:59 AM Damion Dooley ***@***.***> wrote: My point was that all the parthood that one would like to rely upon somehow with UBERON, i.e. just knowing that the heart specimen I have before me has a 'left ventricle instance' and therefore I should see it connected to such and such, can't be taken advantage of. One has to re-create a whole mirrored parthood. Every part of the heart before me has to be declared a processed specimen itself, and all the parthood connections between them established at the instance level? Maybe that's something I didn't realize about instance-level entities that are not in-situ instances of anatomical classes. — Reply to this email directly, view it on GitHub <#204 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADJX2IQFP4AVA4Q476IIVKLW63WNZANCNFSM5WWRKBDQ> . You are receiving this because you were mentioned.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

Answer 8 · 2023-03-31T15:51:14.000Z

Ok, there's hope via property chain then. I'll experiment a bit. I'll see if transitivity involved in inverse relations need to be blocked somehow.