[go] AmiGO and annotation qualifiers

[Chris Mungall]

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
>>
>>
>>
>>
>>
>
>
>