-
Notifications
You must be signed in to change notification settings - Fork 30
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
Comments
I thought you would use RO:0002160 only in taxon to express that "X is specific to the Y taxon" and |
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 ). |
I checked today, and neither RO:0002162 in taxon
RO:0002160 only in taxon
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. |
They won’t be. As explained in the guide I linked:
So the intended meaning of 'in taxon' was implemented instead by ways of disjointness axioms of the form
By themselves, no, but they contradict the following GCI disjointness axiom:
|
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. |
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:
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?”. |
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:
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
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.
The text was updated successfully, but these errors were encountered: