[Go] addition of localization specific process terms ?
Harold Drabkin
hjd at informatics.jax.org
Tue Mar 24 10:50:33 PDT 2009
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?
>>>
More information about the Go
mailing list