make in_taxon functional

[dosumis]

in_taxon has range 'organism' (at least implicitly) .

Comment: Note - we could get the same reasoning results from disjointness axioms: in_taxon some A DisjointWith in_taxon some B

see also #367

[matentzn]

Unfortunately, this is not possible in OWL.

(non-simple property in role chains violation)

We have two options:

1. we make the only_in_taxon functional:
   
2. Introduce a shadow AP "functional" and make in_taxon functional like this - this requires a different reasoner to be used then.

[dosumis]

Where's the role chain? Is this just the property hierarchy?

Don't think we care about 'only in taxon' any more. Happy to make functional + maybe add a note that we now favour in_taxon instead and plan to obsolete at some point?

[matentzn]

Lots of role chains. So the remaining question is this:

1. We make only-in-taxon functional and use that instead of in-taxon - everywhere
2. We leave as is, use in-taxon and not have it functional
   • we could add a QC check for anatomy ontologies that:
     1. Classifies the ontology and materialises in-taxon
     2. Strips out role chains and injects functional characteristic
     3. Classifies again
3. Too much hassle for too little gain (close ticket, no action).

@dosumis you let me know how to proceed.

[cmungall]

@matentzn remember that the functional characteristic is not necessary if the taxon GCIs are included (i.e. in-taxon A DisjointWith in-taxon B, for all sib pairs AB). While this requires plumbling, the plumbing is in place, the GCIs are released with ncbitaxon - otherwise taxon constraints would not have worked for us in GO, Uberon, etc for the last decade!!!

It's on the OBO page for http://obofoundry.org/ontology/ncbitaxon

Makefile here:

https://github.com/obophenotype/ncbitaxon/blob/master/subsets/Makefile#L10-L11

So the choice is

1. We make only-in-taxon functional and use that instead of in-taxon - everywhere
2. We leave as is, use in-taxon and not have it be functional, and rely on GCIs being present

I don't think 3 (status quo) is a viable option.

Deciding between 1 and 2 is a complex engineering tradeoff, but I think 2 is the winner

1. is kind of pointless. If you are within EL, it's useless. Elk doesn't support it. If you are using a DL reasoner, you can use ONLY anyway.
2. Scales for mid to large ontologies (go, uberon). The downside is that the GCIs must be present and synced. Currently this is done as part of the NCBITaxon release, but it seems here institutional knowledge is slipping. Also we only do it for taxslim (which covers most taxa used in ontologies).

[matentzn]

Thank you @cmungall - sorry, forgot about the GCIs.

I agree with your assessment and tend towards 2. Shouldnt these GCIs be shipped with RO (as they are effectively used to restrict the relation)? But I am happy either way. I want to use only taxoslim from now on. Everywhere!

Complete segway: One thing I noticed recently with @balhoff that you can actually exploit a minor flaw in DOSDP to Encode GCIs as background knowledge using the GCI section (with no variables) - basically what would happen in a generation scenario, is that the GCI is simply merged along with the rest of the pattern into OWL.

[dosumis]

I'm happy with the GCI solution . GCIs should live with ncbitaxonomy - maybe as an extension as I can imagine potential use cases for excluding. Species hybrids exist (https://en.wikipedia.org/wiki/Liger) -are esp common in plants where sometimes fertile (https://en.wikipedia.org/wiki/Hybrid_(biology)#In_plants)

[balhoff]

maybe as an extension as I can imagine potential use cases for excluding. Species hybrids exist (https://en.wikipedia.org/wiki/Liger) -are esp common in plants where sometimes fertile (https://en.wikipedia.org/wiki/Hybrid_(biology)#In_plants)

The disjoints we have between sibling taxa will have the same effect as the GCIs when using more expressive OWL. But I think hybrids may not be so much of a problem. It seems like it is valid to say that a Liger is not in the sets of Tigers or Lions, but its parents are.

[cmungall]

Agree

…

On Thu, May 6, 2021 at 1:19 PM Jim Balhoff ***@***.***> wrote: maybe as an extension as I can imagine potential use cases for excluding. Species hybrids exist (https://en.wikipedia.org/wiki/Liger) -are esp common in plants where sometimes fertile ( https://en.wikipedia.org/wiki/Hybrid_(biology)#In_plants) The disjoints we have between sibling taxa will have the same effect as the GCIs when using more expressive OWL. But I think hybrids may not be so much of a problem. It seems like it is valid to say that a Liger is not in the sets of Tigers or Lions, but its parents are. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#459 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAMMOOGRGUF6BXFGTEBSS3TML2U7ANCNFSM43TK6H7Q> .

[cmungall]

We do: http://obofoundry.org/ontology/ncbitaxon

…

On Wed, May 5, 2021 at 2:30 AM David Osumi-Sutherland < ***@***.***> wrote: I'm happy with the GCI solution . GCIs should live with ncbitaxonomy - maybe as an extension as I can imagine potential use cases for excluding. Species hybrids exist (https://en.wikipedia.org/wiki/Liger) -are esp common in plants where sometimes fertile. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#459 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAMMON7TH33T66ZDFJBOMLTMEF3RANCNFSM43TK6H7Q> .

[dosumis]

So we map hybrids up to the nearest common parent taxon (Panthera in this case)?

[cmungall]

not wrong

But I would consider requesting Liger etc from NCBI. NCBITaxon OWL mirrors the NCBI database, down to having the root term be called "root". See obophenotype/ncbitaxon#55

There is a precedent for hybrids

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

cc @nicolevasilevsky as some of this ties into breed ontology - but should probably be moved to ncbitaxon tracker since this is not a RO issue

[nlharris]

jim says: can't be functional (for every x, just one value of y) because involved in a lot of property chains.
issues due to implementation of OWL.

[balhoff]

We discussed at June 1 meeting and will not add the functional characteristic. Projects that want to implement taxon restrictions (we discussed CL) should import the disjoint-in-taxon axioms or use owltools to generate them.