amigo
amigo copied to clipboard
geneontology
Non-GO terms prioritized in general search
I suppose it is "intended" by omission. As long as we expect that people are not searching for non-GO terms (which is perfectly reasonable), we should be filtering out those results.
I will bee to check this, but we may need to add some extra information to the loader to have something to filter out in the request.
The issue is that some GO terms are present in non-GO ontologies (like multicellular). It would be much clearer if non-GO terms were not indexed for the search.
Pascale
I was searching on multicellular which is a string in a GO term. I don't understand why the non GO terms are there...
queries such as: which genes are involved in processes related to B cells? Or similar for chemical entities. But agree there is a tradeoff between advanced used cases and keeping this simple and free of confusion. Suggest product lead @ukemi takes this up, gathers some feedback and use cases + comes up with recommendations
On Wed, Mar 13, 2019 at 4:55 AM Val Wood [email protected] wrote:
I was searching on multicellular which is a string in a GO term. I don't understand why the non GO terms are there...
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/geneontology/amigo/issues/559#issuecomment-472334084, or mute the thread https://github.com/notifications/unsubscribe-auth/AADGOdFCSHEBtWvooB_DU-AzlsMT9VeJks5vWL0VgaJpZM4brCRq .
queries such as: which genes are involved in processes related to B cells?
This would make sense if the terms were used in annotations displayed in Amigo, but why UBEron, PATO and phenotype ontologies? You would not retrieve ny annotation.
I can see value for been able to search on cell type, tissue type of other ontology terms used in extensions? but they need to be used in extant annotations...
Looks like you're on a phone :-)
Uberon is used a lot in extensions, and also linked from existing GO processes. But there should not be any pheno ontologies in there.
GOC meeting discussion topic?
I'd rather not having too open ended and have one proposal or two alternate proposals specified in advance
Oh yes sorry uberon is anatomy isn't it.
Would it be possible to restrict to terms that are used in extensions?
Two proposals: Restrict to only ontologies used in asserted relationships in the ontology OR Restrict to ontologies used in the ontology and annotation extensions.
OR 3 Restrict to ontologies and terms used in the ontology and annotation extensions.
Presumably, these are huge ontologies and only a small subset of terms are used in extensions. Obviously, you want to be able to search on any GO term, but is there any advantage to the user in being to find any term in an ontology that is used in extensions (the entirety of CHEBI?), if it isn't currently connected to a GO annotation in some way. In the PomBAse website query builder, which is more about finding things than seeing every term, we only include the terms we have used in annotations.
Also, are you suggesting in 1 that all terms used in logical definitions are included? is this useful to the general user? We usually shield the user from this, it's complicated enough already. How would the user benefit from the inclusion of these terms?
this behaviour affects searching really badly. I also really dislike that I need to add a space to find an ontology term. If I type only "cell" I don't see any ontology terms, only gene products. I don't think many users would realise that they need to add a space?
This is a real problem. Sometimes I even land on a page and don't notice it's not a GO term http://amigo.geneontology.org/amigo/term/UBERON:0002405
It must be a real problem for users who most likely won't be paying attention to the IDs. Can we discuss at the GO meeting (I still don't fully understand what the use case is )
OK, let's try and summarize and not have the same discussion over again. I closed the duplicate issues.
Background: the reason these are here is because we reference external terms in both the ontology and in extensions.
There is some discussion above about whether we should restrict this to ONLY ontologies used in extensions. But this would not solve the problem, there would still be external ontology terms.
There are two options beyond the status quo, which we all agree is bad:
- no modifications to the software, and we switch amigo to loading only core go
- modify the software to filter/sort/demarcate appropriately
The negative implications of 1 are:
- a. extensions that reference ontology terms would show up as IDs and not labels
- b. the extensions facet would show only IDs and not allow filtering by hierarchy
- c. we limit the ability to do programmatic queries via the golr interface that leverage external ontologies, including such things as finding terms or genes that involve a particular chemical entity from chebi
- d. potential other downsides we need to investigate further, including showing external ontology terms in gocams.
However, the advantage is that is a configuration change only, and we all agree on the benefits.
I will speak to @kltm about how much effort would be involved in adding filters but I suspect that most groups would not mourn the loss of a-c so much, although we should bear in mind that different groups leverage external ontology terms to different extents.
From the technical call and some other conversation threads, I'm noting here that:
- for the ontology filtering approach, we'd need to be careful that and still need ncbitaxon and eco; we might be able to drop cl, uberon, and pato; I'll add this to the managers' call
- since the issue seems to be focused on the "general" document search, it may be possible
- check to make sure that the use of "general" is limited to amigo search
- check to see if there is a filterable structure we could use in the general document
- see how hard it would be to change the owltool loader to just filter for anything not "GO" (or anything else we want to keep)
TODO: We'll ask for an ontology to be built as an experiment and load it on a dev server for the the manages/others to check.