[Go] addition of localization specific process terms ?

[Harold Drabkin]

However, as I was just told, "interleukin" does not describe a family in 
a related sequence sense, but in a functional  sense, so we can't have 
an "interleukin binding" term, so that idea is not good

h

Harold Drabkin wrote:
> Just a quick note: a lot of the children of the protein binding term 
> are used when a family is involved: eg. actin binding, and is useful 
> where the authors did not specify which of several possible actins was 
> involved. In this case, we use IDA instead of IPI, so at least the 
> information that something specifically binds (one of the ) actin.
> I was concerned some time ago when there was a move to add 
> exceedingly  specific terms;  ie, interleukin 6 binding, interleukin 7 
> binding, where typically there is one; these could be handled with 
> protein binding IPI id_of_interleukin 6, or whatever, or perhaps even 
> better,  interleukin binding IPI id_of interleukin 6, so that one 
> could search on what might bind any interleukin, and get back 
> annotations where the specific species can be found n the with field.
>
> h
>
>
> Alexander Diehl wrote:
>> Jim,
>>
>> I don't see the need to prepare ChEBI x binding.  The use of the term 
>> "protein binding" has always been done post-compositionally by MGI 
>> and others, and similarly the use of "binding" in general can be done 
>> post-compositionally.  There are some more specific children of 
>> protein binding, some of which may be more useful than others, but 
>> certainly I would not encourage more without a sound argument.  The 
>> GO is not perfect, but the existing mechanisms for term requests and 
>> generation are pretty good about weeding out unnecessary additions.  
>> If necessary we can propose annotation standards for GO that specify 
>> post-composition for "binding" related terms, as we do already for 
>> "protein binding."
>>
>> While I agree with Jen a new fast term browser might help folks who 
>> have trouble finding terms, in general finding terms does become 
>> faster with experience.  And although the MGI term browser is 
>> primitive in many respects, by default it always shows children of a 
>> given term, which many other browsers do not, thus saving a step when 
>> searching for more specific terms.
>>
>> -- Alex
>>
>>
>> Jim Hu wrote:
>>> In general, I like precomposition too.  But for binding, and to a 
>>> lesser extent location, I don't like the idea of having parent terms 
>>> with thousands of children.  The terms like regulation of 
>>> translation of gene X mRNA are terrifying to me.  I noticed that 
>>> somewhere on wiki.geneontology.org, there's a statement that GO will 
>>> never do those kinds of terms by precomposition, but a few terms 
>>> like that are already in GO, and there was recently a sourceforge 
>>> item about protein chaperones for specific gene products. I usually 
>>> find terms by searching for a keyword combination, navigating to a 
>>> particular term, and then browsing up and down the ontology.  Do 
>>> others not do the browsing part?  I think that's where the massive 
>>> expansion is most problematic.
>>>
>>> I see what you mean about time, but requesting a new term is also a 
>>> time barrier to annotation.
>>>
>>> Perhaps a test version of the ontology could be automatically 
>>> generated with ChEBI x binding, and people could see if my 
>>> intuitions or everyone else's are correct.  In general, I suspect 
>>> that people want precomposition for their own annotations and are 
>>> annoyed at the excess terms that they don't see themselves ever 
>>> using.  E. coli being the most distant from everyone else in the 
>>> phylogeny may be why I'm where I am on this! ;)
>>>
>>> Jim
>>>
>>> On Mar 24, 2009, at 8:38 AM, Alexander Diehl wrote:
>>>
>>>> I want to add my agreement to the words of Val and David.  It is 
>>>> much simpler to use a pre-composed existing term in annotation.  
>>>> One aspect of the annotation process I feel is over looked as we 
>>>> add more complexity to the annotation process is that 
>>>> post-composition adds a significant bit of time to the annotation 
>>>> process, resulting in fewer annotations overall and lower metrics 
>>>> for the database and grant.  While it is important to do detailed 
>>>> and correct annotations whenever possible, anything we can to do to 
>>>> increase throughput, such as precomposing likely terms, is 
>>>> beneficial.  I'm not saying we should add all possible combinations 
>>>> of X and Y, just the appropriate ones.  This is one of the main 
>>>> reasons for having annotators lead ontology development and holding 
>>>> ontology content meetings where expert biologists can discuss 
>>>> processes actually seen in nature, so that the appropriate 
>>>> combinations of X and Y are added.
>>>>
>>>> And knowing which pre-composed terms to use is a matter of training 
>>>> and experience, both in general biology, and in annotation.  
>>>> There's no way around it.
>>>>
>>>> -- Alex
>>>>
>>>>
>>>> val at sanger.ac.uk <mailto:val at sanger.ac.uk> wrote:
>>>>> I agree, it is far better to have pre-composed terms if possible,
>>>>> especially for new curators.
>>>>> As we encourage annotation to the most specific term possible it 
>>>>> is hard
>>>>> to overlook the precomposed terms, because we (I hope) always 
>>>>> check the
>>>>> child terms).
>>>>>
>>>>> Val
>>>>>
>>>>>  
>>>>>> From someone who has been annotating using a lot of 
>>>>>> pre-composition as
>>>>>> well as post-composition for a reasonably long time;  although 
>>>>>> there is
>>>>>> an initial activation energy to get a pre-composed term into the
>>>>>> ontology, once they are there, they are much easier to use than 
>>>>>> to look
>>>>>> up things in multiple ontologies for post-composition.
>>>>>>
>>>>>> The key to finding pre-composed terms easily is to have a good 
>>>>>> way of
>>>>>> viewing the ontology.
>>>>>>
>>>>>> my 2c
>>>>>>
>>>>>> D
>>>>>>  
>>>>>>> I would like to hear the opinion of some of the annotators here. Is
>>>>>>> excessive pre-coordination a concern for curation?
>>>>
>
> _______________________________________________
> Go mailing list
> Go at geneontology.org
> http://fafner.stanford.edu/mailman/listinfo/go