Fix the check for taxon constraint violations #3336
Conversation
Since version 1.5, the ODK import system strips by default almost all annotation properties from the imported modules, except rdfs:label and IAO:0000115. This is intended to reduce the size of the import modules, on the rationale that most annotations are "not important" anyway. Unfortunately, this results in the OMO:0002000 annotation property being stripped from the RO import, and that property is definitely not a "not important" one, since it defines the axioms that ROBOT's `expand` command should inject into the ontology wherever that annotation is used. In particular, the expansion of RO:0002175 (`present_in_taxon`) is a critical step of the check for taxon constraint violations. As a result of OMO:0002000 being stripped, that expansion is not performed, and the taxon constraints check is inoperant -- it has been inoperant ever since we migrated to ODK 1.5, back in March 2024! This commit explicitly declares which annotation properties should be preserved by the ODK when refreshing the import modules, instead of relying on the ODK default (rdfs:label and IAO:0000115), to make sure that OMO:0002000 is among them.
This is to ensure we get the OMO:0002000 annotations back immediately, without waiting for the next time the imports would normally be refreshed.
|
Unfortunately, in the 6 months since we did not have a functioning TC violations check, TC violations did find their way in the ontology. First one:
Possible fix: Removing the following axiom: Without knowing much about the development of the spleen, it seems like a bold claim to state that the spleen primordium is always part of the dorsal mesogastrium, in any species where a spleen (and therefore a spleen primordium) exists. |
|
Next violation:
Here I am skeptical about that property chain:
Just because a “vertebra cartilage element“ may develop into a vertebra should not necessarily imply, I believe, that such elements can only exist in taxa where vertebrae exist. That chain does not exist in upstream RO, it is explicitly added in Uberon: |
|
The last one has its cause in CL, I believe.
According to the taxon notes on placenta labyrinth, Uberon is correct here, so one of the CL assertions is wrong:
|
|
I am very sorry to have caused this - my mental reasoner should have been alert when answering the question: are there Annotation Properties that are needed for logical reasoning - as |
|
It seems the taxon constraint QC is still not working in the GitHub Action. Shouldn't this PR fail and post the comment with the violations? |
Indeed. There are other problems than the non-expansion of OMO:0002000, I am looking into it (I am doing some tests in #3337). From what I can tell for now, there are at least two more problems:
|
OK, that was a false problem, just a side effect of one of the changes I made in #3337 for testing. So, the TC check now (with this PR) is, in fact, working again, it’s just that the ODK 1.5 that we use in CI doesn’t catch what ODK 1.5.2 is catching. @anitacaron @matentzn Any objection to switch to ODK 1.5.2 in Uberon QC? Presumably Anita does the releases with 1.5.2 anyway, so it’d make sense to use 1.5.2 in QC as well. |
I'm not sure, but @wdahdul may also have an opinion about this. |
|
The unsat involving CL’s placental villus capillary endothelial cell has been fixed in CL and a CL release with the fix is already available, so that particular issue will be automatically fixed in Uberon the next time we’ll refresh the imports. As for the issue with the vertebra cartilage element (see comment), editors at the Uberon call of August 19th, 2024 agreed with the proposed removal of the property chain:
I plan to proceed with said removal unless someone objects to it in the next 3 weeks. |
|
Keep the property chain. You can make an RO ticket for me to clarify the relation. Think of it as being there is genetic programming to make A develop into B. It is stronger than "may" (mays-as-existentials-considered-harmful). The fix is to change the individual relationship to potential to develop into some UBERON:0010913 ! vertebral element. |
Will do. But if the property chain is correct, I believe it should belong in RO – that is, the property chain should still be removed from here and added to RO instead. |
There are two
Any of the two is enough to make 'vertebra cartilage element' (which is Changing both of these relationships to So what I propose to do instead:
That is, we would go from this (current hierarchy)
to this:
|
'vertebra cartilage element' violates a taxon constraint because it is present_in_taxon some 'Eptatetrus burgeri' (inshore hagfish) but has_potential_to_develop_into some vertebra, and vertebra is ultimately (through 'vertebral column') never_in_taxon some Myxinidae (hagfishes). We fix that by removing the has_potential_to_develop_into relationship between 'vertebra cartilage element' and 'vertebra'. This is however not enough, as 'vertebra cartilage element' develops_from some 'vertebra pre-cartilage condensation' which also has_potential_to_develop_into some vertebra, providing another path to unsatisfiability. We fix that by changing the target of the has_potential_to_develop_into relationship of 'vertebra pre-cartilage condensation' from 'vertebra' to 'vertebra cartilage element'.
'red pulp of spleen' violates a taxon constraint because it is present_in_taxon some 'Danio rerio' but is linked (through 'spleen primordium', from which the spleen develops) to stomach, which is never_in_taxon some 'Danio rerio'. We fix that by removing the following axiom: 'spleen primordium' part_of some 'dorsal mesogastrium' That axiom is what links the existence of the spleen to the existence of the stomach, and is probably too strong a claim. If a spleen can exist in species without a stomach (as is the case in zebrafish), then the spleen primordium cannot always be part of a component of the stomach.
'placental villus capillary endothelial cell' (from CL) was violating a taxon constraint. This has been fixed in CL already, so here we import the fix directly in our merged_import module (rather than refreshing the entire module).
Since last November, we normally have a check in place to automatically detect any violations of the taxon constraints set forth in the ontology.
Unfortunately, since we migrated to ODK 1.5 back in March, that check has been neutered. This is because the ODK 1.5 defaults to stripping most annotation properties from the imported modules. One of the properties that ended up being stripped is
OMO:0002000(“defined by construct”), which is used by ROBOT‘s expand command to inject constructed axioms into the ontology wherever the annotation is used. In particular, the expansion ofRO:0002175(“present in taxon“) is a critical step in the aforementioned check for violations of taxon constraints. Without that property,RO:0002175is, in effect, meaningless, and we cannot enforce any constraint that depends on it.This PR updates the ODK configuration to stop it from stripping the
OMO:0002000annotation property when refreshing the imports, thereby restoring the enforcement of taxon constraints.My sincerest apologies to the Uberon community for having missed that issue not once, but twice: when we implemented the annotation stripping in ODK 1.5 and when we first updated the imports here after the 1.5 migration.