Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Newly introduced crab and lobster terms violate taxon constraints #3454

Closed
gouttegd opened this issue Dec 23, 2024 · 6 comments · Fixed by #3455
Closed

Newly introduced crab and lobster terms violate taxon constraints #3454

gouttegd opened this issue Dec 23, 2024 · 6 comments · Fixed by #3455
Assignees

Comments

@gouttegd
Copy link
Collaborator

gouttegd commented Dec 23, 2024

All terms introduced in the recently merged PR #3445 (merged despite a failure of the CI check, please don’t do that…) violate taxon constraints.

This is because all those terms have the same following two assertions:

'in taxon' some Astacidea
'in taxon' some Brachyura

This is likely a misunderstanding of the meaning of the 'in taxon' relation. “X 'in taxon' some Y” means that X is specific to the Y taxon, i.e. X cannot exist in any other taxon that is not Y or a descendant of Y. From that meaning, it follows that a term should never have more than one 'in taxon' assertion; once a term has been asserted to be 'in taxon' some Y1, any other assertion 'in taxon' some Y2 will cause a contradiction, unless Y2 happens to be exactly equivalent to Y1.

If you want to state that an anatomical entity is “known to exist in a given taxon“ but without implying anything about its existence in other taxa, what you need is 'present in taxon'.

If you want to state that an anatomical entity exists in a handful of taxa T1, T2, ... Tn, exclusive of all other taxa, then 'in taxon' is the correct relation but you need to find the closest parental taxon that encompasses all the T1, T2, ... Tn taxa. In the present case, Astacidea and Brachyura are both subtaxa of Pleocyemata, so the correct way to state that an anatomical entity only exists in Astacidea and Brachyura is

'in taxon' some Pleocyemata


Uberon contributors: Please ensure you read and understand the guide to taxon constraints before adding/editing assertions that involve taxon constraints (any assertion that uses one of 'in taxon', 'never in taxon', present in taxon').

Uberon reviewers: Please do not merge a PR if the CI check failed -- at least not without asking a member of the “tech team“ first. It can happen that sometimes a CI failure is caused by “external“ factors (e.g. network issues), and in that case and in that case only it may be fine to proceed with merging the PR despite the failure. But do not merge a PR with a failed check unless you know for sure it is an instance of an external problem.

@rays22
Copy link
Collaborator

rays22 commented Dec 23, 2024

This is likely a misunderstanding of the meaning of the 'in taxon' relation. “X 'in taxon' some Y” means that X is specific to the Y taxon, i.e. X cannot exist in any other taxon that is not Y or a descendant of

I thought you would use RO:0002160 only in taxon to express that "X is specific to the Y taxon" and x only in taxon y if and only if x is in taxon y, and there is no other organism z such that y!=z a and x is in taxon z..

@gouttegd
Copy link
Collaborator Author

I thought you would use RO:0002160 only in taxon to express that "X is specific to the Y taxon"

This may have been originally the intended difference between 'in taxon' and 'only in taxon' (I wouldn’t know), but if it was that intent has since changed. 'only in taxon' now has exactly the same meaning as 'in taxon', and in fact 'only in taxon' is due to be obsoleted precisely because it is completely redundant with 'in taxon' (see in particular this comment from @balhoff ).

@rays22
Copy link
Collaborator

rays22 commented Dec 23, 2024

I checked today, and neither in taxon nor only in taxon has been made functional yet.
My understanding of the difference between current RO textual definitions of in_taxon and only_in_taxon are the following:

RO:0002162 in taxon

  • if y and z are taxa, and y disjoint with z
  • ASSERTION 1: x in_taxon y
  • ASSERTION 2: x in_taxon z

RO:0002160 only in taxon

  • if y and z are taxa, and y disjoint with z
  • ASSERTION 1: x only_in_taxon y
  • ASSERTION 2: x only_in_taxon z
  • (x only_in_taxon y) AND (x only_in_taxon z) = FALSE
    • then ASSERTION 1 DOES contradict ASSERTION 2.
    • For example, and assertion(vertebra only_in_taxon Vertebrata) AND (vertebra only_in_taxon Arthropoda) SHOULD contradict each other.

I am not sure I understand how and why in_taxon is being intended/used in ways that appears to contradict the current RO definitions. For error checking, I would use only_in_taxon and then there would be no need to obsolete either.

@gouttegd
Copy link
Collaborator Author

I checked today, and neither in taxon nor only in taxon has been made functional yet.

They won’t be. As explained in the guide I linked:

The most intuitive solution to this problem would be to assert that in_taxon is a functional property. However, due to limitations of OWL, functional properties can't be used in combination with property chains. Furthermore, functional properties aren't part of OWL EL.

So the intended meaning of 'in taxon' was implemented instead by ways of disjointness axioms of the form 'in taxon' some T1 DisjointWith: 'in taxon' some T2, where T1 and T2 are sibling taxa.

For example, (striated muscle tissue in_taxon Vertebrata) AND (striated muscle tissue in_taxon Arthropoda) do not contradict each other.

By themselves, no, but they contradict the following GCI disjointness axiom:

'in taxon' some Protostomia' DisjointWith: 'in taxon' some Deuterostomia

@rays22
Copy link
Collaborator

rays22 commented Dec 23, 2024

I checked today, and neither in taxon nor only in taxon has been made functional yet.

They won’t be. As explained in the guide I linked:

  1. The public facing definitions do not know about what will happen in the future. I would not expect our collaborators to try to read the intentions of people from github discussions. That is my point.

The most intuitive solution to this problem would be to assert that in_taxon is a functional property. However, due to limitations of OWL, functional properties can't be used in combination with property chains. Furthermore, functional properties aren't part of OWL EL.

So the intended meaning of 'in taxon' was implemented instead by ways of disjointness axioms of the form 'in taxon' some T1 DisjointWith: 'in taxon' some T2, where T1 and T2 are sibling taxa.

For example, (striated muscle tissue in_taxon Vertebrata) AND (striated muscle tissue in_taxon Arthropoda) do not contradict each other.

By themselves, no, but they contradict the following GCI disjointness axiom:

'in taxon' some Protostomia' DisjointWith: 'in taxon' some Deuterostomia

  1. The GCIs are not part of the public facing RO definitions. These GCIs may well solve problems, but people from the community are expected to read and use public facing definitions when trying to contribute to Uberon.
  2. If there is a contradiction introduced by the GCI disjointness axiom for the assertions 1. (striated muscle tissue in_taxon Vertebrata) and 2. (striated muscle tissue in_taxon Arthropoda) , then it is not a biologically valid contradiction. Striated muscle is not exclusive to Deuterosomia, see for example the muscles of insects or other invertebrates.

Bottom line, do the changes as you intend. However, until the RO definitions are not aligned with the intentions, then it is inevitable to run into some misunderstanding.

@gouttegd
Copy link
Collaborator Author

I fully agree that RO textual definition of 'in taxon' should be amended to clearly reflect its meaning.

But I hard disagree on the idea (that you seem to imply) that textual definitions are the only thing that editors should know about, and that as long as they have read the textual definition of the relation they want to use they don’t need to know anything else.

The Uberon editors SOP clearly states that editors should read and understand the aforementioned guide before editing any axiom involving a taxon constraint:

Before adding any taxon restrictions, make sure go through this guide and understand the implications of the taxon restriction and how to properly add them.

My note to all Uberon editors at the end of the ticket was merely a reminder of that. Taxon constraints are a powerful tool that can render an entire ontology inconsistent, and they should not be used lightly. And whenever a PR fails because of a taxon restriction, this should lead the contributor to pause and ask, “wait, did I do everything correctly?”.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants