[Go] addition of localization specific process terms ?
Midori Harris
midori at ebi.ac.uk
Wed Mar 4 01:56:27 PST 2009
Yes - I don't have much to add, but I agree with everything Val says
(including what she attributes to me ;) ).
m
On Wed, 4 Mar 2009, Valerie Wood wrote:
> Because of all of the arguments in favour mentioned by Karen and Chris I
> thought it was always necessary and required for curators to make the more
> granular annotation in these cases. We decided long ago that proliferation of
> the ontology was not an issue when pitched against accurate capture of
> biology, and I wasn't aware that it was ever GO philosophy not to capture
> compartment specific processes in this way.
>
> Another 'for' arguement is that, the more specific terms can have additional
> parentage. For example, mitochondrial DNA replication, can have parents to
> mitochondrial genome maintenance and mitochondrial organization, which would
> not be possible if there was no mitochondrial replication term. This would
> make lots more work as you would need to make concurrent annotations to
> 'mitochondrial genome maintenance' and 'DNA replication".
> I spoke to Midori about after the meeting and apparently the terms which it
> was agreed to purge from GO for this reason (very early in GO) were those
> which combined Component and Function (not Process), so this may be the
> source of the confusion. Apparently some mitochondrial processes got purged
> at the same time (i.e mitochondrial translation), but these were subsequently
> added back.
>
> Val
>
>
>
> Chris Mungall wrote:
>
>>
>> First, just to emphasize an important point:
>>
>> An annotation to a term "P that occurs_in C" carries *more* information
>> than two independent annotations to P and C. This can be seen if we have 4
>> annotations, to P1, P2, C1 and C2. Currently we have no way of knowing if
>> this means that P1 occurs_in C1 or C2 or neither or both, and similarly
>> for P2.
>>
>> Thus we need a way to annotate to "P that occurs_in C" if we are to begin
>> to fully capture the biology. There are two options
>>
>> 1. post-compose
>> http://wiki.geneontology.org/index.php/Annotation_Cross_Products
>> - annotate to P and C as normal, using two annotations
>> - in the annotation for P, put "occurs_in(C)" in col17
>>
>> 2. pre-compose: create a term "P that occurs_in C"
>> (and optionally for now, but required in the future, add the XP
>> definition[*])
>>
>> So your question is: how do we know when to choose 1 vs 2?
>>
>> My own personal guideline is whether or not the location of P is an
>> 'accidental' property of P, or something fundemental.
>>
>> For example: translation in the forebrain is (I am guessing) not
>> fundamentally different from translation in the midbrain. The cellular
>> machinery goes through roughly the same sequence of steps using the same
>> materials. You can imagine 'transplanting' the process. There's not much
>> you would say in the definition of this term other than - translation that
>> occurs in the forebrain.
>>
>> However, mitochondrial translation is fundamentally different from nuclear
>> translation because a different genetic code is used.
>>
>> This argues strongly for "forebrain translation" being annotated by
>> composing the description at annotation time (annotation xp), and
>> mitochondrial translation being pre-composed in the ontology (and
>> logically defined in bp_xp_cc).
>>
>> Of course, I deliberately chose a clear cut example. Other cases will be
>> more difficult. But this isn't a worry, because the two methods are
>> logically equivalent, so long as we keep bp_xp_cc up to date, and are
>> clear about which relations to use.
>>
>> Cheers
>> Chris
>>
>> [*] see
>> http://wiki.geneontology.org/index.php/XP:biological_process_xp_cellular_component
>>
>> On Mar 3, 2009, at 3:16 PM, Karen Christie wrote:
>>
>>> Hi,
>>>
>>> In last week's Reference Genomes annotation jamboree, a question came
>>> up about whether/when it is appropriate to add localization specific
>>> process terms. We'd like clarification of the GOC's current practice
>>> on this issue. More details are below.
>>>
>>> thanks,
>>>
>>> -Karen
>>>
>>>
>>>
>>> We were discussing the appropriate process terms for the LONP1 group
>>> of genes, which are involved in proteolysis of proteins in the
>>> mitochondrial matrix. The question came up regarding whether it would
>>> be appropriate to have a specific term for mitochondrial proteolysis,
>>> considering that we already have terms like:
>>>
>>> - ER-associated protein catabolic process (GO:0030433)
>>> - mitochondrial translation (GO:0032543)
>>>
>>> At one time, the philosophy on this was to have one term representing
>>> the basic process, and to indicate localizations using the component
>>> annotations. However, more recently, terms such as the two listed
>>> above have been added to GO.
>>>
>>>
>>> Arguments in favor of localization specific process terms included:
>>>
>>> -- 1. the fact that a different set of genes is involved in a given
>>> "process", e.g. mitochondrial translation versus cytoplasmic
>>> translation
>>>
>>> -- 2. being able to look for terms enriched in a process such as
>>> "mitochondrial translation", without having to also use a component
>>> term to narrow the search to the mitochondrial genes (this is
>>> apparently not possible in many tools)
>>>
>>>
>>> Arguments against having localization specific process terms included:
>>>
>>> -- 1. unnecessary proliferation of terms in the ontology, since the
>>> localization can be obtained via the component annotations
>>>
>>>
>>> So, for going forwards, we'd like clarification of when it is or is
>>> not appropriate to request localization specific process terms and on
>>> the guiding principles for deciding when/if such terms are appropriate.
>>>
>>> thanks,
>>>
>>> -Karen
>>>
>>> _______________________________________________
>>> Go mailing list
>>> Go at geneontology.org
>>> http://fafner.stanford.edu/mailman/listinfo/go
>>>
>>
>> _______________________________________________
>> Go mailing list
>> Go at geneontology.org
>> http://fafner.stanford.edu/mailman/listinfo/go
>>
>>
>>
>
>
>
>
More information about the Go
mailing list