In some cases, AmiGO-loaded ontologies seem sub-optimal

[kltm]

There seem to be some cases there seem to be child explosions for some terms. For example, around nucleus, worm anatomy seems to have taken over:

http://amigo.geneontology.org/amigo/term/GO:0005634#display-lineage-tab http://amigo.geneontology.org/amigo/term/WBbt:0002543#display-lineage-tab

Initially reported by @tberardini

[kltm]

The question here is whether or not this is the intended or desired behavior?

[tberardini]

Observed by @lreiser first - she will likely be able to provide other examples

[kltm]

It might be nice to have additional checks on the ontology that look at something like fan-out--it may be possible to detect these before making it out the door.

[lreiser]

This is the first time I have ever seen this before or even noticed the CARO terms (which I understand now to be common anatomy reference ontology. IMHO it is not 'ideal' to have but hey... I am a plant biologist...worm folks might think this is bomb.

[cmungall]

This is completely logically coherent yet utterly undesirable to show these. In general it is confusing when external onts show up in amigo. We have a banner but it's not v visible. Yet there are use cases for these

On Wed, Oct 23, 2019, 16:01 kltm notifications@github.com wrote:

There seem to be some cases there seem to be child explosions for some terms. For example, around nucleus, worm anatomy seems to have taken over:

http://amigo.geneontology.org/amigo/term/GO:0005634#display-lineage-tab http://amigo.geneontology.org/amigo/term/WBbt:0002543#display-lineage-tab

Initially reported by @tberardini https://github.com/tberardini

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/geneontology/go-ontology/issues/18048?email_source=notifications&email_token=AAAMMOJDDDZTMI343ZMTA3TQQDJUXA5CNFSM4JEMN4GKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HT6UFDQ, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAMMOMW3PQJYJHXN7VUVHDQQDJUXANCNFSM4JEMN4GA .

[tberardini]

There's no banner on the GO term view (nucleus) and that's where the explosion is visible.

[lreiser]

I get that external terms do show -like CHEBI and PO and all though I don't recall a previous case where the ontologies were quite so...blended. Im a PC scientist and all but for my purposes (using AmiGO to browse ontology terms and in some cases, view children terms to find more specific terms) the visibility WITHIN the GO ontology renders the tool useless for curation.

[balhoff]

@kltm was there a switch from go-gaf to go-lego in Amigo?

[kltm]

@balhoff This is what we've been using for some time: https://github.com/geneontology/pipeline/blob/1ae45d4d39a6b87c06bed2789a02db44a9d973fc/Jenkinsfile#L91

[balhoff]

I see, this connection from worm nuclei to GO nucleus is not in go-gaf but in WBbt, which is also being loaded into GOLR.

[pgaudet]

What is the use case for showing no-GO term in the search results ?

[ValWood]

I don't know why we show non-GO terms. I have been moaning about this for a while. I default to quickGO now. Are these at all useful for biologist end users who are only interested in the GO term for their gene of interest?

[srengel]

I also use QuickGO and never AmiGO, because of stuff like this that makes AmiGO useless for curation.

[vanaukenk]

Just checking - is there anything we should be doing differently in the WBbt ontology?

[lreiser]

I guess I never noticed it or this was the first experience had with quite so many descendants that it made it impossible to focus just on the GO terms. I can try using QuickGO.

[cmungall]

use cases are extensions, query by cell type make use of relationships in CL, our choices are (1) dedicate resources to properly separating (2) exclude these ontologies from load, so we lose this, ext terms will show up as IDs

On Thu, Oct 24, 2019 at 9:12 AM lreiser notifications@github.com wrote:

I guess I never noticed it or this was the first experience had with quite so many descendants that it made it impossible to focus just on the GO terms. I can try using QuickGO.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/geneontology/go-ontology/issues/18048?email_source=notifications&email_token=AAAMMONQHMMRPPZ4DXQCBPDQQHCNDA5CNFSM4JEMN4GKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECFSVVA#issuecomment-545991380, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAMMOK6PFQE7PIMCSY3WD3QQHCNDANCNFSM4JEMN4GA .

[tberardini]

exclude these ontologies from load, so we lose this, ext terms will show up as IDs

What does that mean? The 'tree' will look the same but now the term names of all the worm nuclei are not shown, only the IDs are visible? I'm not sure that's much better.

When trying to decide which way to go, it's worth considering the number of users who would benefit from having the 'blown-up' ontology visible vs. those who suffer or turn to other resources because of the explosion.

[cmungall]

it would be gone for the tree, but IDs would be shown in the extensions field and in the extensions facet. We could try something where we just load the labels but this will take a bit of work to get right

On Thu, Oct 24, 2019 at 3:17 PM Tanya Berardini notifications@github.com wrote:

exclude these ontologies from load, so we lose this, ext terms will show up as IDs

What does that mean? The 'tree' will look the same but now the term names of all the worm nuclei are not shown, only the IDs are visible? I'm not sure that's much better.

When trying to decide which way to go, it's worth considering the number of users who would benefit from having the 'blown-up' ontology visible vs. those who suffer or turn to other resources because of the explosion.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/geneontology/go-ontology/issues/18048?email_source=notifications&email_token=AAAMMOPPTRBZGGEJGHVVI73QQING7A5CNFSM4JEMN4GKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECGTNDI#issuecomment-546125453, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAMMOMNLMWTWEFKHW7GYY3QQING7ANCNFSM4JEMN4GA .

[pgaudet]

Hi,

I think the usability issues are with the search results - it's good to show external vocabularies for extensions, but NOT in the search.

Issues are

1. Non-GO terms should NOT be returned in the search results
2. Obsolete terms should be weighted down
3. Space/return action should be made more intuitive

I made a few slides showing how I use AmiGO and what I expect: https://docs.google.com/presentation/d/1kq4ze9oe1nwJl7M26H0leYwbc518q1P5rq-hvYVrlE8/edit?usp=sharing

Thanks, Pascale

[ValWood]

I would possibly like to search on the extensions, but not to see the terms in the ontology tree.

This would make extension searches behave the same for ontology terms and other objects in extensions like gene products. At PomBase we have many more gene products (3382) than external ontology terms. So the extension search needs to work for these too. The search also needs to distinguish the annotated gene product from the extension the results.

Possibly when searching on a gene product I would want to find the a)the gene product, and b which other gene products it was an extension for, eg

When searching on extensions, however, we should think about the usefulness of the results with the current annotations. For example is you expected to be able to search on a cell type and get all of the gene products or processes you'd be disappointed. Use cases would be good.

If we can't provide users with sensible results because the annotation coverage is too low then it isn't so urgent to present users with a way into these urgently (even while they are useful to see if present)

So

• What are the questions that can be asked by querying extension? We need use cases

• If you perform these queries identified as potentially useful do you get the expected results based on annotation coverage.

• If so can the search solution be optimised to work for currently available data, and what users will need longer term.

So for example as a user I might want to . search on "AB nucleus" and find all the genes annotated to this term (none!) See my point about when the annotation makes this useful. It's not really useful if it isn't annotated to.

But I wouldn't want to see "AB nucleus" as a child of GO:nucleus when GO graph browsing.

[lreiser]

"but I wouldn't want to see "AB nucleus" as a child of GO:nucleus when GO graph browsing."

+1

[ukemi]

Is this an ontology issue or an AmiGO issue. It's imperative that from an ontology perspective we have these vocabularies available to us, if not for class references we certainly need the closure for GO-CAMs.

[cmungall]

Amigo

On Wed, Oct 30, 2019, 10:26 David Hill notifications@github.com wrote:

Is this an ontology issue or an AmiGO issue. It's imperative that from an ontology perspective we have these vocabularies available to us, if not for class references we certainly need the closure for GO-CAMs.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/geneontology/go-ontology/issues/18048?email_source=notifications&email_token=AAAMMONXJQ7MU2JHCWIL2IDQRG7THA5CNFSM4JEMN4GKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECVCL7I#issuecomment-548021757, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAMMOK5NP7VCOBY3PSQVETQRG7THANCNFSM4JEMN4GA .

[cmungall]

Having said that wbbt is a bit odd and unconventional here, subclassing nucleus

On Wed, Oct 30, 2019, 11:51 Chris Mungall cjmungall@lbl.gov wrote:

Amigo

On Wed, Oct 30, 2019, 10:26 David Hill notifications@github.com wrote:

Is this an ontology issue or an AmiGO issue. It's imperative that from an ontology perspective we have these vocabularies available to us, if not for class references we certainly need the closure for GO-CAMs.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/geneontology/go-ontology/issues/18048?email_source=notifications&email_token=AAAMMONXJQ7MU2JHCWIL2IDQRG7THA5CNFSM4JEMN4GKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECVCL7I#issuecomment-548021757, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAMMOK5NP7VCOBY3PSQVETQRG7THANCNFSM4JEMN4GA .

[cmungall]

Assume it is to do with lineage tracking but not clear why not use cell like other AOs

On Wed, Oct 30, 2019, 11:52 Chris Mungall cjmungall@lbl.gov wrote:

Having said that wbbt is a bit odd and unconventional here, subclassing nucleus

On Wed, Oct 30, 2019, 11:51 Chris Mungall cjmungall@lbl.gov wrote:

Amigo

On Wed, Oct 30, 2019, 10:26 David Hill notifications@github.com wrote:

Is this an ontology issue or an AmiGO issue. It's imperative that from an ontology perspective we have these vocabularies available to us, if not for class references we certainly need the closure for GO-CAMs.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/geneontology/go-ontology/issues/18048?email_source=notifications&email_token=AAAMMONXJQ7MU2JHCWIL2IDQRG7THA5CNFSM4JEMN4GKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECVCL7I#issuecomment-548021757, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAMMOK5NP7VCOBY3PSQVETQRG7THANCNFSM4JEMN4GA .

[cmungall]

duplicate with https://github.com/geneontology/amigo/issues/559