Open ValWood opened 5 years ago
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 notifications@github.com 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 .
GOC meeting discussion topic?
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
How about only ontologies used in GO?
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 )
Same as #649
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:
The negative implications of 1 are:
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:
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.
I find this really annoying and not useful: Is this intended?