search

obophenotype / uberon

An ontology of gross anatomy covering metazoa. Works in concert with https://github.com/obophenotype/cell-ontology
http://obophenotype.github.io/uberon/
Other
134 stars 29 forks source link

Logical axioms from external relationships found in edit file #2453

Open anitacaron opened 2 years ago

anitacaron commented 2 years ago

After I did cleansing in #2377, some logical axioms are only present in UBERON.

[Typedef] id: capable_of name: capable of xref: RO:0002215 is_a: functionally_related_to ! functionally related to

[Typedef] id: connected_to name: connected to xref: RO:0002170 is_a: transitively_connected_to ! transitively_connected to

[Typedef] id: continuous_with name: continuous with xref: RO:0002150 is_symmetric: true

[Typedef] id: develops_from name: develops from xref: RO:0002202 is_a: has_developmental_contribution_from ! has developmental contribution from

[Typedef] id: drains name: drains xref: RO:0002179 domain: UBERON:0001638 ! vein

[Typedef] id: has_branching_part name: has branching part xref: RO:0002569 is_transitive: true

[Typedef] id: has_developmental_contribution_from name: has developmental contribution from xref: RO:0002254 is_transitive: true

[Typedef] id: has_skeleton name: has skeleton xref: RO:0002551 domain: UBERON:0000475 ! organism subdivision range: UBERON:0010912 ! subdivision of skeleton

[Typedef] id: immediately_posterior_to name: immediately posterior to xref: BSPO:0015012 is_a: adjacent_to ! adjacent_to

[Typedef] id: immediately_superficial_to name: immediately superficial to xref: BSPO:0015014 is_a: adjacent_to ! adjacent_to

[Typedef] id: in_lateral_side_of name: in lateral side of xref: BSPO:0000126 disjoint_from: in_central_side_of ! in_central_side_of

[Typedef] id: in_taxon name: in taxon xref: RO:0002162 holds_over_chain: attaches_to in_taxon holds_over_chain: connected_to in_taxon holds_over_chain: connects in_taxon holds_over_chain: continuous_with in_taxon holds_over_chain: developmentally_induced_by in_taxon holds_over_chain: existence_ends_during in_taxon holds_over_chain: existence_starts_during in_taxon holds_over_chain: extends_fibers_into in_taxon holds_over_chain: has_potential_to_develop_into in_taxon holds_over_chain: innervated_by in_taxon holds_over_chain: overlaps in_taxon holds_over_chain: produced_by in_taxon holds_over_chain: produces in_taxon holds_over_chain: supplies in_taxon

[Typedef] id: innervated_by name: innervated_by xref: RO:0002005 transitive_over: branching_part_of ! branching_part_of

[Typedef] id: simultaneous_with name: simultaneous with xref: RO:0002082 is_a: ends ! ends is_a: starts ! starts

[Typedef] id: supplies name: supplies xref: RO:0002178 domain: UBERON:0001637 ! artery

matentzn commented 2 years ago

Just to say it, fantastic work on the non-base axioms @anitacaron.

@cmungall @dosumis it is now up to you to decide which axioms should go in RO, and which ones should be discarded. Once we know (just edit @anitacaron comment to indicate if something is bad), just comment "ok to move the rest to RO" and we will take care of the rest

Thank you!

dosumis commented 2 years ago

[Typedef] id: capable_of name: capable of xref: RO:0002215 is_a: functionally_related_to ! functionally related to

This is already in RO (indirectly)

transitively_connected_to is not in RO. Having a transitive superProperty of connected_to is dangerous for reasoning. It can make pre-reasoning of existentials blow up massively. So, I'd be reluctant to include it in RO. @cmungall ?

[Typedef] id: connected_to name: connected to xref: RO:0002170 is_a: transitively_connected_to ! transitively_connected to

[Typedef] id: continuous_with name: continuous with xref: RO:0002150 is_symmetric: true

[Typedef] id: develops_from name: develops from xref: RO:0002202 is_a: has_developmental_contribution_from ! has developmental contribution from

[Typedef] id: drains name: drains xref: RO:0002179 domain: UBERON:0001638 ! vein

[Typedef] id: supplies name: supplies xref: RO:0002178 domain: UBERON:0001637 ! artery

[Typedef] id: has_branching_part name: has branching part xref: RO:0002569 is_transitive: true

Looks reasonable, although potential for massive proliferation of trivial inferences.

[Typedef] id: has_developmental_contribution_from name: has developmental contribution from xref: RO:0002254 is_transitive: true

Based on definition "x has developmental contribution from y iff x has some part z such that z develops from y"@en This is wrong and so should not be in RO.

[Typedef] id: has_skeleton name: has skeleton xref: RO:0002551 domain: UBERON:0000475 ! organism subdivision range: UBERON:0010912 ! subdivision of skeleton

I think the domain maybe too strict. Doesn't my foot have a skeleton. Is a foot an organism subdivision?

[Typedef] id: immediately_posterior_to name: immediately posterior to xref: BSPO:0015012 is_a: adjacent_to ! adjacent_to

[Typedef] id: immediately_superficial_to name: immediately superficial to xref: BSPO:0015014 is_a: adjacent_to ! adjacent_to

[Typedef] id: in_lateral_side_of name: in lateral side of xref: BSPO:0000126 disjoint_from: in_central_side_of ! in_central_side_of

[Typedef] id: in_taxon name: in taxon xref: RO:0002162 holds_over_chain: attaches_to in_taxon holds_over_chain: connected_to in_taxon holds_over_chain: connects in_taxon holds_over_chain: continuous_with in_taxon holds_over_chain: developmentally_induced_by in_taxon holds_over_chain: existence_ends_during in_taxon holds_over_chain: existence_starts_during in_taxon holds_over_chain: extends_fibers_into in_taxon holds_over_chain: has_potential_to_develop_into in_taxon holds_over_chain: innervated_by in_taxon holds_over_chain: overlaps in_taxon holds_over_chain: produced_by in_taxon holds_over_chain: produces in_taxon holds_over_chain: supplies in_taxon

These are used to extend taxon inference (and therefore are useful in the generation of taxon slims). The general principle seems to be that anything with a relationship to a term with a taxon restriction will inherit that restriction. On the one hand, it seems like this could expand in RO to cover many more relationships given that in_taxon is used in so many different contexts. Based on usage I'd say domain & range = 'biological entity' where that could be continuant or occurrent. But there is also some danger of these chains causing bleed through to contexts where they shouldn't apply e.g. if part_of links an individual to a population ?

See https://github.com/geneontology/go-ontology/issues/23012#issuecomment-1076710729 for a script-based solution to specifying chains over in_taxon

[Typedef] id: simultaneous_with name: simultaneous with xref: RO:0002082 is_a: ends ! ends is_a: starts ! starts

anitacaron commented 2 years ago

[Typedef] id: develops_from name: develops from xref: RO:0002202 is_a: has_developmental_contribution_from ! has developmental contribution from

seems reasonable to add to RO

has_developmental_contribution_from is already a sibling of develops_from.

Should it still be added to RO?

matentzn commented 2 years ago

Yes add for now and see what happens.

cmungall commented 2 years ago

I agree with all @dosumis comments

happy to drop transitively_connected_to, it's useful and safe for certain shapes of TBox but queries can always inject this where needed

I think adding uberon domains/ranges for supplies/drains is too restricted for RO. We could either (1) rename to a more specific relation (2) add the domains/ranges back as universal restrictions (obv not ideal for Elk)

has_skeleton domain: this may be a case of a domain trying to do the closed-world work of a DP. Although I am not sure it's particularly problematic either - foots/autopods are organism subdivisions

I am not so sure has-developmental-contribution transitivity is wrong but happy to go with this for now and take anything involving development RO axioms to a dedicated issue

github-actions[bot] commented 1 year ago

This issue has not seen any activity in the past 6 months; it will be closed automatically one year from now if no action is taken.

anitacaron commented 1 year ago

From Chris' comment https://github.com/obophenotype/uberon/issues/2453#issuecomment-1148850497

I think adding uberon domains/ranges for supplies/drains is too restricted for RO. We could either (1) rename to a more specific relation (2) add the domains/ranges back as universal restrictions (obv not ideal for Elk)

[Typedef] id: drains name: drains xref: RO:0002179 domain: UBERON:0001638 ! vein

[Typedef] id: supplies name: supplies xref: RO:0002178 domain: UBERON:0001637 ! artery

@dosumis what do you think? Which option could we take?

Related to the has_skeleton domain:

has_skeleton domain: this may be a case of a domain trying to do the closed-world work of a DP. Although I am not sure it's particularly problematic either - foots/autopods are organism subdivisions

[Typedef] id: has_skeleton name: has skeleton xref: RO:0002551 domain: UBERON:0000475 ! organism subdivision range: UBERON:0010912 ! subdivision of skeleton

@dosumis:

dosumis commented 1 year ago

Please retain - moving to Uberon. These are highly likely to be doing useful work in Uberon. Removing or broadening would require looking at & carefully considering the modelling consequences, which should be done int he context of work on the vasculature/skeleton.

matentzn commented 1 year ago

If @cmungall thinks the domains and ranges are too restrictive for RO, the proper path would be to create new object properties and have them be subclasses of their RO counterparts.. We should never inject axioms like this into our ontologies - they will definitely leak!

matentzn commented 1 year ago

Suggestion from pattern call:

Create specific relationships and transfer the semantics to these.

anitacaron commented 1 year ago

What would be the name of these specific relations?

matentzn commented 1 year ago

Lets say

"supplies artery" "drains artery"

or

"supplies vessel" "drains vessel"

cmungall commented 1 year ago

these would have to be inverted, e.g. "vessels supplies", as the domain is the vessel

I think either

"supplies circulatory fluid to" / "drains circulatory fluid from"

or

"supplies tissue" / "drains tissue"

the latter is maybe confusing to ontologists as the asserted ranges are not tissues in the CARO sense, but ultimately the vessels are supplying tissues, we may just choose to make the assertion at the level of organs or organ parts.

This is a good question to take to a new top level issue and get input from the ASCT-B folks

On Sun, Mar 19, 2023 at 10:14 AM Nico Matentzoglu @.***> wrote:

Lets say

"supplies artery" "drains artery"

or

"supplies vessel" "drains vessel"

— Reply to this email directly, view it on GitHub https://github.com/obophenotype/uberon/issues/2453#issuecomment-1475325763, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAMMOLVXGLCKOFILYWBGWLW445IRANCNFSM5VC6Y23Q . You are receiving this because you were mentioned.Message ID: @.***>

dosumis commented 1 year ago

https://github.com/oborel/obo-relations/issues/699

github-actions[bot] commented 10 months ago

This issue has not seen any activity in the past 6 months; it will be closed automatically one year from now if no action is taken.

gouttegd commented 1 month ago

Status as of October 2024:

(A) The following injected axioms in Uberon are already present in RO.

It should therefore be uncontroversial that we can drop those injections from Uberon.

The remaining Uberon-specific injections are:

(B) 'has skeleton'

In RO, that relation is range-restricted to 'anatomical structure' and domain-restricted to 'material anatomical entity'.

Corresponding RO ticket: https://github.com/oborel/obo-relations/issues/700. Last comment in that ticket suggests that we should stick to the RO-defined range and domain and drop the Uberon injections.

(C) drains Domain: vein

RO has added 'vessel drains blood from', which is domain-restricted to 'blood vessel' -- slightly more lax than the Uberon injection, but I think it is good enough and we can drop our injection (and start using that new relation instead of drains)?

(D) supplies Domain: artery

Likewise, RO has recently added 'vessel supplies blood to' which is domain-restricted to 'blood vessel'. Again, I think it is good enough for Uberon?

(E) 'innervated by' o 'branching part of' SubPropertyOf: 'innervated by'

Unless I missed something, I don’t think this one has been discussed.

(F) All the property chains over 'in taxon'

Not really discussed (again unless I missed something) apart from @dosumis’ comment:

These are used to extend taxon inference (and therefore are useful in the generation of taxon slims). The general principle seems to be that anything with a relationship to a term with a taxon restriction will inherit that restriction. On the one hand, it seems like this could expand in RO to cover many more relationships given that in_taxon is used in so many different contexts. Based on usage I'd say domain & range = 'biological entity' where that could be continuant or occurrent. But there is also some danger of these chains causing bleed through to contexts where they shouldn't apply e.g. if part_of links an individual to a population ?

To which I would add that for now, the fact that those property chains are only defined in Uberon means that taxon constraints are understood differently in Uberon and in CL, which cannot be good. I am strongly in favour of moving all those property chains to RO.

gouttegd commented 1 month ago

Regarding drains and supplies:

Replacing them by the more specific relations '(vessel) drains blood from' and '(vessel) supplies blood to' would cause the following problems, all due to the fact that the more specific relations are range-restricted to 'anatomical structure':

I don’t think that asking RO to drop the range restriction to 'anatomical structure' would be the correct solution -- that restriction seems OK to me, relaxing it to allow saying that a vessel supplies or drains blood to or from an immaterial entity would be weird.

For supraorbital artery, a likely solution could be to establish the relationship with 'mucosa of frontal sinus' rather than the frontal sinus itself?

For intercostal artery, a possible solution would be to replace

'intercostal artery' SubClassOf: 'supplies blood to' some 'intercostal space'

by individual relationships to the various elements found in the intercostal space such as 'intercostal muscle' and 'intercostal lymph node'.

However this is not really applicable to 'intercostal vein' because for that term, the relationship is part of the logical definition:

'intercostal vein' EquivalentTo: vein and ('drains blood from' some 'intercostal space')

A possibly better solution would be to add a new term like “intercostal element”, defined as

'anatomical structure' and ('located in' some 'intercostal space')

and then use the new term to define both intercostal artery:

'intercostal artery' SubClassOf: 'supplies blood to' some 'intercostal element'

and 'intercostal vein':

'intercostal vein' EquivalentTo: vein and ('drains blood from' some 'intercostal element')