[Ontology-editors] CC, PRO and CORUM

Wed Nov 26 09:22:54 PST 2008

So long as we have a way to indicate "inactive" then yes, it would mean 
permanently inactivated (because it would require some 
transformation/derivation to make it active).  It is my understanding 
that the GO CC complexes are implicitly active.

Chris Mungall wrote:
> 
> Does "inactive" mean permanently inactived? If not then the potential is 
> still there.
> 
> But if this still seems unnatural, one solution would be to implicitly 
> treat all GO CCs as the active form. For the more specific PRO inactive 
> form, PRO would represent a complex that is_a "inactivated_complex" and 
> transformation_of the GO active CC.
> 
> A similar solution could be used with derives_from, where PRO wants to 
> represent specific forms that have gained or lost parts.
> 
> On Nov 26, 2008, at 7:32 AM, Darren Natale wrote:
> 
>> Yes, that is exactly my understanding.  So, if GO had "unicornase 
>> complex" and PRO were to have something like "inactive unicornase 
>> complex" and "active unicornase complex," it seems to me that only the 
>> active version has the potential function.  I think we'd want to 
>> connect both to GO somehow, but which relation to use isn't yet clear 
>> to me.
>>
>> Midori Harris wrote:
>>> Hi Darren,
>>> In addition to what Judy says, I think it's reasonable to interpret 
>>> the function-centric portions of many GO CC definitions as indicating 
>>> that a complex has the potential to execute a function (though it's 
>>> true that the defs aren't explicitly worded that way).
>>> Midori
>>> On Wed, 26 Nov 2008, Judith Blake wrote:
>>>> Darren,
>>>>
>>>> I think the complexes in GO are not meant to be function-specific, 
>>>> they are meant to be location-specific.  So is_a would be correct.  
>>>> If the definitions are not location specific, such as XX complex 
>>>> is_a cellular component, then the GO definition should be modified.
>>>>
>>>> judy
>>>>
>>>> -----Original Message-----
>>>> From: Darren Natale [mailto:dan5 at georgetown.edu]
>>>> Sent: Wednesday, November 26, 2008 10:20 AM
>>>> To: Judith Blake
>>>> Cc: Midori Harris; Chris Mungall; Ontology Editors
>>>> Subject: Re: [Ontology-editors] CC, PRO and CORUM
>>>>
>>>>
>>>>
>>>> Judith Blake wrote:
>>>>> I concur with Midori here.  The purpose of the generation of this 
>>>>> set was to expand the representation in GO for those complexes 
>>>>> missing that are important in the mammalian system.  For this CORUM 
>>>>> provided a great portal for my summer intern to identify and work 
>>>>> with generating the intersection of the GO and CORUM sets.
>>>>>
>>>>> However, as Midori notes, the definitions provided need to be 
>>>>> generalized for the GO context.  And, as noted, there are more 
>>>>> complexes to be represented as well.  I think the use of the CORUM 
>>>>> set as a starting point is proving productive however, and I'm glad 
>>>>> to see the extension of complex representation in GO.
>>>>>
>>>>> The work of the moment, then, is to establish how we will represent 
>>>>> the relationship between the context-dependent 
>>>>> (species/celltype/space/time) representation in PRO and the generic 
>>>>> representation in GO.
>>>>
>>>> My initial thought was that is_a would be appropriate.  I think Chris
>>>> expressed the same idea.  However, I'm no longer certain that this is
>>>> the case.  For example, the inactive form of a complex--which would 
>>>> also
>>>> be represented in PRO--would not fit the function-based definitions 
>>>> that
>>>> are sometimes used in GO.  Technically speaking I suppose part_of could
>>>> be used (Chris, correct me if I am wrong but I think the definition of
>>>> part_of allows for saying some whole part_of itself).  I don't really
>>>> like that, however.  Needs more thought.
>>>>
>>>>> This does not address the other issue as to whether 'complexes', 
>>>>> because of their context dependence should be classified 
>>>>> differently than the cellular structures such as the mitochondria 
>>>>> or golgi.
>>>>>
>>>>> Judy
>>>>>
>>>>> -----Original Message-----
>>>>> From: Midori Harris [mailto:midori at ebi.ac.uk]
>>>>> Sent: Wednesday, November 26, 2008 9:29 AM
>>>>> To: Chris Mungall
>>>>> Cc: Ontology Editors; Darren Natale; Judith Blake
>>>>> Subject: Re: [Ontology-editors] CC, PRO and CORUM
>>>>>
>>>>> Hi Chris,
>>>>>
>>>>> As noted briefly yesterday, I'm gradually working my way through 
>>>>> the many
>>>>> suggested new complex terms in SF 2049652, and Jane has taken on a 
>>>>> subset
>>>>> in SF 2125996. It's very slow going, because I'm finding that I 
>>>>> have to
>>>>> check each term manually, and that often requires reading (or at least
>>>>> skimming) much of the full text of a paper.
>>>>>
>>>>> Based on what I'm finding, I would not incorporate anything into GO 
>>>>> based
>>>>> on importing or mapping anything from CORUM or MIPS. The Sin3 complex
>>>>> example is fine, but there are problems with enough of the CORUM 
>>>>> entries
>>>>> I've looked at to make me very leery of trying to speed up adding the
>>>>> complex terms. For example, CORUM cites PMID:11713266 for more 
>>>>> different
>>>>> complexes than the paper shows; CORUM:3284 is a separate entry 
>>>>> based on a
>>>>> paper that actually shows that a particular protein is a member of a
>>>>> previously identified complex; for CORUM:832 the paper cited 
>>>>> actually says
>>>>> that two of the listed subunits are found in *different* complexes.
>>>>>
>>>>> Even for the accurately described complexes, the localization (and 
>>>>> maybe
>>>>> also function and process) may be species-specific in some cases, and
>>>>> those wouldn't meet our all-some criteria. Like the composition (and
>>>>> existence!) of the complexes themselves, localizations might have 
>>>>> to be
>>>>> individually vetted.
>>>>>
>>>>> For those CORUM complexes that do pass the curator vetting 
>>>>> procedure, I'll
>>>>> be able to pull GO IDs and CORUM IDs out of a spreadsheet if we 
>>>>> want to
>>>>> add dbxrefs.
>>>>>
>>>>> midori
>>>>>
>>>>> [snip PRO stuff]
>>>>>
>>>>>> * Mapping CORUM to GO.
>>>>>>
>>>>>> I see we have 18 CC terms with synonyms with CORUM as provenance. 
>>>>>> It may be
>>>>>> an idea to have a separate xref too (e.g. if the CORUM name is 
>>>>>> identical). So
>>>>>> there's another ~1200 to be added? I couldn't find the tracker 
>>>>>> item for this.
>>>>>>
>>>>>> There are quite a few that could be trivially mapped. E.g:
>>>>>>
>>>>>> [Term]
>>>>>> id: GO:0016580
>>>>>> name: Sin3 complex
>>>>>> namespace: cellular_component
>>>>>> def: "A multiprotein complex that functions broadly in eukaryotic 
>>>>>> organisms
>>>>>> as a transcriptional repressor of protein-coding genes, through the
>>>>>> gene-specific deacetylation of histones. Amongst its subunits, the 
>>>>>> Sin3
>>>>>> complex contains Sin3-like proteins, and a number of core proteins 
>>>>>> that are
>>>>>> shared with the NuRD complex (including histone deacetylases and 
>>>>>> histone
>>>>>> binding proteins). The Sin3 complex does not directly bind DNA 
>>>>>> itself, but is
>>>>>> targeted to specific genes through protein-protein interactions with
>>>>>> DNA-binding proteins." [PMID:10589671, PMID:11743021, PMID:12865422]
>>>>>> is_a: GO:0000118 ! histone deacetylase complex
>>>>>>
>>>>>> To:
>>>>>>
>>>>>> http://mips.gsf.de/genre/proj/corum/complexdetails.html?id=54
>>>>>>
>>>>>> Note that MIPS localizes this to the nucleus. Can we just import MIPS
>>>>>> localizations, or are they not as rigorous as us in forcing an 
>>>>>> all-some
>>>>>> relation?
>>>>>>
>>>>>> Once we have these we can also use mips2go and the mips funcat 
>>>>>> entry for each
>>>>>> complex to get CC->MF/MP links
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Ontology-editors mailing list
>>>>>> Ontology-editors at geneontology.org
>>>>>> http://fafner.stanford.edu/mailman/listinfo/ontology-editors
>>>>
>>
> 