obsolete only_in_taxon

[cmungall]

trafficstars

replaced-by: in-taxon

Add Functional characteristic to in-taxon

also consider: relabeling in-taxon to in-organism

[zhengj2007]

The relation only_in_taxon is not deprecated in the latest RO release: http://purl.obolibrary.org/obo/ro/releases/2020-12-18/ro.owl

http://purl.obolibrary.org/obo/RO_0002160

[cmungall]

Obsoleting it is logically problematic, see #459

[balhoff]

I don't think we should retain only_in_taxon just for it being 'functional', so we should proceed with this.

[balhoff]

We discussed in the June 1 RO meeting and want to flesh out the overall docs on taxon constraints before announcing an obsoletion of this term.

[github-actions[bot]]

This issue has not seen any activity in the past 2 years. It will be closed automatically 60 days from now if no action is taken.

[pgaudet]

Hello,

@alexsign from GOA/EBI and I looked at this again today, and it seems. 'only in taxon' should be kept, but moved under the 'logical macro assertion' branch, as a sibling to 'never in taxon'.

It seems right that it doesn't belong in the 'evolutionarily related to' branch:

Thanks for considering this,

Pascale

[dosumis]

@pgaudet - I think important to move all 'only in taxon' assertions to 'in taxon' - I believe that there is no substantive logical difference and doing so will keep existing reasoning mechanisms functioning.

[pgaudet]

should it not be a sibling in RO to 'never in taxon' then?

[dosumis]

If I understand correctly, the aim of the ticket is to replace with only_in_taxon with in_taxon.

AP: never_in_taxon X is a short-cut for not (in_taxon some X). This expansion is implemented in some pipelines where it does useful work in reasoning.

I believe that in every place with use only_in_taxon we want to assert: X in_taxon some Y <--- This is a really important assertion to have when reasoning about taxa - esp in combination with assertion of pairwise disjointness for taxonomy.

The name might imply that we also want to assert X in_taxon only Y

But we don't use this expansion in any current pipelines for scaling reasons, and I'm not sure it's needed.

[alexsign]

@dosumis

But we don't use this expansion in any current pipelines for scaling reasons, and I'm not sure it's needed.

However, this might not be the case for all other GO consortium groups. The GOA actually using logic only_in_taxon (and descendants) and not in any other taxon to do checking. As I understand, in_taxon will not cover this exclusion, or am I wrong?

[dosumis]

However, this might not be the case for all other GO consortium groups. The GOA actually using logic only_in_taxon (and descendants) and not in any other taxon to do checking. As I understand, in_taxon will not cover this exclusion, or am I wrong?

Yes. Here is an example. Say GO defines lactation as a mammalian specific process involving secretion from mammary glands and records this with the restriction: in_taxon some mammalia. At a later date someone mistakenly adds a term for crop millk production (Pigeons product crop milk to feed their chicks) as a subClassOf lactation, adding in_taxon Columbidae (pigeons) leads to an inconsistency (i.e. finds this error) as long as the ontology records that nothing can be '"in taxon' some X" AND '"in taxon' some Y" where X and Y are sibling taxa. In OWL:

This process is used by some of the Uberon pathways and scales well.

You can use your graph based approach to do this with in_taxon (implicitly assuming the pairwise disjointness) - the 'only' doesn't add anything.

If you want to record that something is found in a taxon but may also be in sibling taxa, you should use the AP: 'present in taxon' - which has it's own expansion.

[dosumis]

There is a pattern we could use with only that uses simpler disjointness axioms:

But reasoning with this doesn't scale well.

I don't see the point of having both 'in taxon' and 'only in taxon' when we can use 'present in taxon' to assert the less strict case.

[pgaudet]

Does that mean that we can use multiple 'in taxon' statements rather than the taxon unions we have been using in GO?

[alexsign]

@dosumis I don't understand this example. How crop milk related Mammalia? Mammalian milk is product of mammary glands of mammals. This can be only_in_taxon mammalia. Crop milk is a section of the lower esophagus. It does not exist in mammalia. Both seems to be perfect examples of only_in_taxon case actually. Why dont we just keep only_in_taxon and you can ignore it to make your reasonable scalable. I think we need to add more curators to this discussion too.

[dosumis]

@dosumis I don't understand this example. How crop milk related Mammalia? Mammalian milk is product of mammary glands of mammals. This can be only_in_taxon mammalia. Crop milk is a section of the lower esophagus. It does not exist in mammalia. Both seems to be perfect examples of only_in_taxon case actually. Why dont we just keep only_in_taxon and you can ignore it to make your reasonable scalable. I think we need to add more curators to this discussion too.

The point of the example is that the biology is wrong and the reasoner detects that - just as your graph based approach would. I have updated the text of the comment to make that clearer.

You have two use cases:

1. Record that a process is only found in some specific taxon - "in taxon" already does that (see example above).
2. Record that a process is present in some specified taxon without asserting that it only is only present in that taxon 'present in taxon' does that. (Both of these assume pairwise disjoint taxonomies).

So we do not need 3 relations: 'in taxon', 'only in taxon', 'present in taxon' - just two for these two use cases.

The suggestion here is to merge 'only in taxon' into 'in taxon'. Perhaps to avoid confusion, we should keep 'only in taxon' as the name of the property we use for 1.

It is extremely important that we have a solution that works for everyone and that GO does not unilaterally implement it's own solution. Lots of pipelines depend on a common solution.

[balhoff]

There is simply no difference between only_in_taxon and in_taxon. They are just two different identifiers. In the ontology only_in_taxon is a subProperty of in_taxon, so in_taxon is always implied if only_in_taxon is used. All the property chaining is implemented in terms of in_taxon. Above we said we should hold off on obsoleting this until we had more comprehensive documentation of how reasoning with in_taxon works. I created that a while back, so we should have come back to this issue. Here are the docs: https://oboacademy.github.io/obook/explanation/taxon-constraints-explainer/

[dosumis]

Does that mean that we can use multiple 'in taxon' statements rather than the taxon unions we have been using in GO?

No. With pairwise disjointness asserted, you would end up with inconsistencies as in my above example.

[cmungall]

Summary:

We should obsolete only_in_taxon. Everyone should use in_taxon, it is logically equivalent, because we have the GCI-disjoints in the ncbitaxon release.

We should work with the various groups that use this (GO/CL/Uberon/PR) to ensure their pipelines have migrated before obsoleting.