[go] AmiGO and annotation qualifiers

[Judith Blake]

could this be a case where the duplicate annotations between GOA and RGD 
were not filtered out by RGD because of the change from UniProt to 
UniProtKB?

judy

Chris Mungall wrote:
>
> I'm a bit confused here.
>
> this appears to show a reference contradicting itself w.r.t Adrm1 in 
> RGD. We saw this in the last demo we looked at for this, and it turned 
> out to be a data error in the FlyBase exports.
>
> There doesn't appear to be any NOT annotation in the RGD files. 
> Perhaps this is just fake annotation for the demo?
>
> As an aside, I see RGD have changed:
> RGD     RGD:69248       Adrm1           GO:0008538      
> RGD:1600115     ISS     UniProt:Q16186  F       adhesion regulating 
> molecule 1          gene    taxon:10116     20070710        UniProt
>
> to:
> UniProtKB       Q9JMB5  ADRM1_RAT               GO:0008538      
> UniProt:Q9JMB5  ISS     UniProtKB:Q16186        F       Adrm1, Gp110: 
> Protein ADRM1     IPI00204510     protein taxon:10116     
> 20070420        UniProtKB
>
> Shouldn't gene IDs be used for consistency, except perhaps where there 
> is alternate splicing?
>
>
>
> On Jan 30, 2008, at 2:58 PM, Judith Blake wrote:
>
>> I like the first one and I like including the qualifiers in AmiGO.
>> http://www.ebi.ac.uk/~aji/demo.html The first one is the clearest.  I 
>> actually had to look around the others to find the qualifiers.
>> I think the default /should/ include the NOTs.  If a newbie is 
>> concerned, they can ask go-help or look around for documentation.  
>> NOTs are important.
>>
>> by nngene products do you mean the '3 associations' thing?  I have no 
>> idea what that means.
>>
>> judy
>>
>> Amelia Ireland wrote:
>>> Hi GO Consortium,
>>>
>>> There has been some discussion in the web presence working group 
>>> about the display of NOT annotations and annotations with 
>>> qualifiers. There are two issues; how to display the annotations 
>>> with qualifiers, and how gene product counts for terms with 
>>> qualifiers should be displayed. We'd like to get some feedback from 
>>> the consortium on these issues before releasing the new AmiGO.
>>>
>>> Annotations With Qualifiers
>>> ===========================
>>>
>>> I've made some mock ups of different possible arrangements here:
>>>
>>> http://www.ebi.ac.uk/~aji/demo.html
>>> http://www.ebi.ac.uk/~aji/demo2.html
>>> http://www.ebi.ac.uk/~aji/demo3.html
>>>
>>> These pages are viewing the GPs annotated to a term (and its 
>>> children), but a similar arrangement will be used to view the terms 
>>> with which a GP is associated.
>>>
>>> Which arrangement is the clearest? Things to consider:
>>>
>>> - how easy is it to see inconsistent annotations, e.g. the same GP 
>>> has a normal and a NOT annotation?
>>>
>>> - is it clear what the qualifier applies to?
>>>
>>> - some views (e.g. having the associations with operators/qualifiers 
>>> separated out) require extra calculations to generate and will hence 
>>> be slower
>>>
>>> - should the default view contain NOT annotations? Is a GO newbie 
>>> going to understand them?
>>>
>>> - is the 'nn gene products' link unambiguous in meaning? Is it 
>>> helpful to know how many GPs there are annotated to a term?
>>>
>>>
>>> Gene Product Counts
>>> ===================
>>>
>>> The WPWG discussed generating separate totals for numbers of GPs 
>>> annotated to a term without any qualifier and the no. of GPs 
>>> annotated to a term with each of the other qualifiers (currently the 
>>> GP count for a term *includes* any GPs annotated with 
>>> 'contributes_to' and 'colocalizes_with', but *excludes* NOT 
>>> annotations). How useful would this be, and is it intuitive to split 
>>> the counts up thus, or is it confusing (especially for GO newbies)? 
>>> There is also this to bear in mind:
>>>
>>> On 24 Jan 2008, at 20:11, Chris Mungall wrote:
>>>> On Jan 24, 2008, at 11:08 AM, Seth Carbon wrote:
>>>>> *) ask chris about splitting the gp count by qualifier (seth)
>>>>
>>>> you mean by contributes_to, the NOT operator etc?
>>>>
>>>> unfortunately it is expensive to pre-compute the gp counts in any 
>>>> way that a single gp can end up in two partitions.
>>>>
>>>> we currently partition by gp db name - no gp can be in > 1. this 
>>>> has the advantage that we can get the correct total by summing the 
>>>> numbers at query time.
>>>>
>>>> however, if we have a partition that does not split gps in this way 
>>>> we can't sum across the partitions, which means we have to 
>>>> pre-compute for all combinations.
>>>>
>>>> This may not be so bad for the qualifiers however, since the 
>>>> qualifiers are relatively rare.
>>>>
>>>> would you really want this for the NOT operator though? remember 
>>>> the semantics are easy to get confused here. Would you want:
>>>>
>>>> all gps that are NOT GPCRs (ie include those that are asserted 
>>>> not-TM receptor in the count) - negation propagates up the graph
>>>>
>>>> all gps that have a NOT annotation to some kind of GPCR - negation 
>>>> propagates as normal
>>>
>>>
>>>
>>> Any feedback would be gratefully received. Thanks!
>>>
>>> Amelia / the Web Presence Working Group.
>>>
>>> -- 
>>> Amelia Ireland
>>> GO Editorial Office,
>>> European Bioinformatics Institute, UK.
>>> Carbon neutral driving: http://www.targetneutral.com/TONIC/index.jsp
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>