From rama at genome.Stanford.EDU Fri Jun 1 10:29:40 2007 From: rama at genome.Stanford.EDU (Rama Balakrishnan) Date: Fri, 1 Jun 2007 10:29:40 -0700 Subject: [go] May Annotation outreach report Message-ID: Hello all, I'm about to compile the May report on GO annotation outreach (I am temporarily filling in for Jen). During the month of May, if you took part any activities that encourages or enables new groups to start contributing annotation to the GO consortium would it be possible to write and let me know about it? Updates on ongoing projects are much appreciated. Thanks, Rama From jdeegan at ebi.ac.uk Mon Jun 4 08:43:59 2007 From: jdeegan at ebi.ac.uk (Jennifer Deegan (nee Clark)) Date: Mon, 04 Jun 2007 16:43:59 +0100 Subject: [go] Jennifer Clark's new name Message-ID: <4664333F.6020605@ebi.ac.uk> Hi, Thanks to all who wrote with good wishes for my wedding, which took place three weeks ago. It was very kind of you all. I am back from my honeymoon now and I have a new name! I am now called Jennifer Deegan. In e-mail and papers and conferences I'll be Jennifer Deegan nee Clark so that hopefully people will still realise it's me. So if you start getting friendly e-mail from a stranger called Jennifer Deegan with an e-mail address jdeegan @ ebi.ac.uk then it's really me. Thanks ever so much for taking the time to update your address books and memories. If you would like to see wedding photos then please do write. I have them online but I guess having them archived on the GO list might be overkill. :-) Thanks and best wishes, Jennifer -- Jennifer Deegan (nee Clark) EMBL-European Bioinformatics Institute Gene Ontology Consortium From midori at ebi.ac.uk Tue Jun 5 02:24:31 2007 From: midori at ebi.ac.uk (Midori Harris) Date: Tue, 5 Jun 2007 10:24:31 +0100 (BST) Subject: [go] Ontology development - May highlights Message-ID: Dear GO, The most recent monthly report on ontology content, for May 2007, is now available at: http://gocwiki.geneontology.org/index.php/May2007_ontology_report Some highlights from May: * We're continuing to collaborate with the Harvard & MIT "GO Engineering" group. They are preparing a manuscript to submit to to Nature Genetics as a Perspectives piece. (http://gocwiki.geneontology.org/index.php/Collaboration_with_MIT_GO-Engineering). * More work on transporter terms in the molecular function ontology (http://wiki.geneontology.org/index.php?title=Transporters). * Work has begun on cardiovascular physiology, with a content meeting planned for this month (http://gocwiki.geneontology.org/index.php/Cardiovascular_physiology/development). * Planning and preparatory work are continuing for a content meeting on muscle development, in collaboration with Giorgio Valle, Erika Feltrin, and several muscle experts at the University of Padua (http://wiki.geneontology.org/index.php/Muscle_Development). * Process terms for rRNA processing are being revamped (http://gocwiki.geneontology.org/index.php/RNA_processing). Additional plans for June include revisiting cross-products with the Cell Ontology and ChEBI, and the rRNA processing work will be finished. As usual, details of small- and medium-scale changes are available in the SourceForge Curator Requests tracker. Please contact us if you want to help out with ontology work in a particular area, or if you have any comments or questions about what's going on. Midori & David on behalf of GO's ontology developers From jdeegan at ebi.ac.uk Tue Jun 5 08:49:20 2007 From: jdeegan at ebi.ac.uk (Jennifer Deegan (nee Clark)) Date: Tue, 05 Jun 2007 16:49:20 +0100 Subject: [go] Alert: Proposal to obsolete GO:nnnnnnn: term that impacts existing annotation Alert: Proposal to obsolete GO:nnnnnnn: term that impacts existing annotation Alert: Proposal to obsolete GO:nnnnnnn: term that impacts existing annotation Alert: Proposal to obsolete GO:nnnnnnn: term that impacts existing annotation Alert: Proposal to obsolete GO:nnnnnnn: term that impacts existing annotation Alert: Proposal to obsolete GO:nnnnnnn: term that impacts existing annotation Message-ID: <46658600.2040507@ebi.ac.uk> Alert: Proposal to obsolete GO:nnnnnnn: term that impacts existing annotation Alert: Proposal to obsolete GO:nnnnnnn: term that impacts existing annotation Alert: Proposal to obsolete GO:nnnnnnn: term that impacts existing annotation Proposal to obsolete type I-V protein secretor activity terms that impacts existing annotation Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, The proposal has been made to obsolete terms for which there exist today annotations as follows (data from AmiGO): GO:0015428 type I protein secretor activity 0 objects GO:0015447 type II protein secretor activity TIGR: 1 object GO:0015448 type III protein (virulence-related) secretor activity 0 objects GO:0015449 type IV protein (DNA-protein) secretor activity TIGR: 2 object GO:0015323 type V protein secretor activity TIGR: 2 object ============================================================== External references: ------------------------------------------------------------- GO:0015428 type I protein secretor activity closeInterPro (1) * IPR003997 closePRINTS (1) * PR01490 RTXTOXIND closeTC (1) * 3.A.1.-.- -------------------------------------------------------------- GO:0015447 type II protein secretor activity closeMultiFun (1) * 4.3.A.5 The Type II (General) Secretory Pathway (IISP) Family closeTC (1) * 3.A.5.-.- closeTIGR_TIGRFAMS (1) * TIGR02120 general secretion pathway protein F -------------------------------------------------------------- GO:0015448 type III protein (virulence-related) secretor activity closeInterPro (12) * IPR003065 * IPR003282 * IPR003283 * IPR003520 * IPR003522 * IPR005773 * IPR012670 * IPR012671 * IPR012673 * IPR013348 * IPR013349 * IPR013354 closeMultiFun (1) * 4.3.A.6 The Type III (Virulence-related) Secretory Pathway (IIISP) Family closePfam (3) * PF02523 InvE * PF03519 Invas_SpaK * PF09025 YopR_core closePRINTS (5) * PR01305 SSPAKPROTEIN * PR01337 TYPE3OMGPROT * PR01338 TYPE3OMKPROT * PR01339 TYPE3OMOPROT * PR01344 INVEPROTEIN closeProDom (1) * PD016047 Invas_SpaK closeTC (1) * 3.A.6.-.- closeTIGR_TIGRFAMS (7) ---------------------------------------------------------------------- GO:0015449 type IV protein (DNA-protein) secretor activity closeMultiFun (1) * 4.3.A.7 The Type IV (Conjugal DNA-Protein Transfer) Secretory Pathway (IVSP) Family closeTC (1) * 3.A.7.-.- ----------------------------------------------------------------------- GO:0015323 type V protein secretor activity closeGenProtEC (1) * 4.2.A.64 The Type V Secretory Pathway (VSP) or Twin Arginine Targeting (Tat) Family closeTC (1) * 2.A.64.-.- ========================================================== N.B. Obsoleting only the function terms; cellular component terms for the same systems will be left in place. Function ontology term obsoletion reasons: - The community does not use the terminology employed - Use of an "umbrella" molecular function term is ill-suited to several of the secretion systems. Consequence: - A number of the proteins annotated to the cellular component terms for the secretion complexes will have unknown molecular function - This accurately reflects the state of the field, and specific molecular functions (binding, cleaving, etc) can be added as they are characterized. UNLESS OBJECTIONS ARE RECEIVED BY 21st June WE WILL ASSUME THAT YOU AGREE TO THIS CHANGE. Thanks, and best wishes, Jen (On behalf of the transporter activity working group ) -- Jennifer Deegan (nee Clark) EMBL-European Bioinformatics Institute Gene Ontology Consortium From jdeegan at ebi.ac.uk Tue Jun 5 08:59:40 2007 From: jdeegan at ebi.ac.uk (Jennifer Deegan (nee Clark)) Date: Tue, 05 Jun 2007 16:59:40 +0100 Subject: [go] Alert: Proposal to obsolete I-V protein secretor activity term that impacts existing annotation Message-ID: <4665886C.1070207@ebi.ac.uk> (Without crazy mail client editing problems this time.) Hi, The proposal has been made to obsolete terms for which there exist today annotations as follows (data from AmiGO): GO:0015428 type I protein secretor activity 0 objects GO:0015447 type II protein secretor activity TIGR: 1 object GO:0015448 type III protein (virulence-related) secretor activity 0 objects GO:0015449 type IV protein (DNA-protein) secretor activity TIGR: 2 object GO:0015323 type V protein secretor activity TIGR: 2 object ============================================================== External references: ------------------------------------------------------------- GO:0015428 type I protein secretor activity closeInterPro (1) * IPR003997 closePRINTS (1) * PR01490 RTXTOXIND closeTC (1) * 3.A.1.-.- -------------------------------------------------------------- GO:0015447 type II protein secretor activity closeMultiFun (1) * 4.3.A.5 The Type II (General) Secretory Pathway (IISP) Family closeTC (1) * 3.A.5.-.- closeTIGR_TIGRFAMS (1) * TIGR02120 general secretion pathway protein F -------------------------------------------------------------- GO:0015448 type III protein (virulence-related) secretor activity closeInterPro (12) * IPR003065 * IPR003282 * IPR003283 * IPR003520 * IPR003522 * IPR005773 * IPR012670 * IPR012671 * IPR012673 * IPR013348 * IPR013349 * IPR013354 closeMultiFun (1) * 4.3.A.6 The Type III (Virulence-related) Secretory Pathway (IIISP) Family closePfam (3) * PF02523 InvE * PF03519 Invas_SpaK * PF09025 YopR_core closePRINTS (5) * PR01305 SSPAKPROTEIN * PR01337 TYPE3OMGPROT * PR01338 TYPE3OMKPROT * PR01339 TYPE3OMOPROT * PR01344 INVEPROTEIN closeProDom (1) * PD016047 Invas_SpaK closeTC (1) * 3.A.6.-.- closeTIGR_TIGRFAMS (7) ---------------------------------------------------------------------- GO:0015449 type IV protein (DNA-protein) secretor activity closeMultiFun (1) * 4.3.A.7 The Type IV (Conjugal DNA-Protein Transfer) Secretory Pathway (IVSP) Family closeTC (1) * 3.A.7.-.- ----------------------------------------------------------------------- GO:0015323 type V protein secretor activity closeGenProtEC (1) * 4.2.A.64 The Type V Secretory Pathway (VSP) or Twin Arginine Targeting (Tat) Family closeTC (1) * 2.A.64.-.- ========================================================== N.B. Obsoleting only the function terms; cellular component terms for the same systems will be left in place. Function ontology term obsoletion reasons: - The community does not use the terminology employed - Use of an "umbrella" molecular function term is ill-suited to several of the secretion systems. Consequence: - A number of the proteins annotated to the cellular component terms for the secretion complexes will have unknown molecular function - This accurately reflects the state of the field, and specific molecular functions (binding, cleaving, etc) can be added as they are characterized. UNLESS OBJECTIONS ARE RECEIVED BY 21st June WE WILL ASSUME THAT YOU AGREE TO THIS CHANGE. Thanks, and best wishes, Jen (On behalf of the transporter activity working group ) -- Jennifer Deegan (nee Clark) EMBL-European Bioinformatics Institute Gene Ontology Consortium From jdeegan at ebi.ac.uk Tue Jun 5 09:12:49 2007 From: jdeegan at ebi.ac.uk (Jennifer Deegan (nee Clark)) Date: Tue, 05 Jun 2007 17:12:49 +0100 Subject: [go] Alert: Proposal to obsolete GO:0015096 manganese resistance permease that does not impact existing annotation Message-ID: <46658B81.4060607@ebi.ac.uk> Hi, The proposal has been made to obsolete GO:0015096 manganese resistance permease. There exist today no annotations to this term (data from AmiGO). *The term is used in the following mappings: closeTC (1) * 9.A.17.2.2 The reasons for this proposal are that the term is undefined and we don't know the mechanism so we can't make a correct definition. UNLESS OBJECTIONS ARE RECEIVED BY 19th June WE WILL ASSUME THAT YOU AGREE TO THIS CHANGE. Thanks, Jen (On behalf of the transporter activity working group.) -- Jennifer Deegan (nee Clark) EMBL-European Bioinformatics Institute Gene Ontology Consortium From rama at genome.Stanford.EDU Tue Jun 5 13:37:54 2007 From: rama at genome.Stanford.EDU (Rama Balakrishnan) Date: Tue, 5 Jun 2007 13:37:54 -0700 Subject: [go] May annotation outreach report Message-ID: <7A17E3B1-3FEC-4843-B84C-90BA0590E469@genome.stanford.edu> Hi All, The outreach working group report for the month of May is available on the Wiki- http://gocwiki.geneontology.org/index.php/May_2007_Monthly_Report Enjoy! Rama From ma11 at gen.cam.ac.uk Wed Jun 6 01:20:00 2007 From: ma11 at gen.cam.ac.uk (Michael Ashburner) Date: Wed, 6 Jun 2007 09:20:00 +0100 Subject: [go] May annotation outreach report In-Reply-To: <7A17E3B1-3FEC-4843-B84C-90BA0590E469@genome.stanford.edu> References: <7A17E3B1-3FEC-4843-B84C-90BA0590E469@genome.stanford.edu> Message-ID: <856F80F4-8A38-4A51-9F85-AEF39F520FC2@gen.cam.ac.uk> Do you want detailed comments on flow charts yet, or latter ? Look good, but in general I suggest a very conservative use of colors and keep these non-garish ! Michael On 5 Jun 2007, at 21:37, Rama Balakrishnan wrote: > Hi All, > > The outreach working group report for the month of May is available > on the Wiki- > > http://gocwiki.geneontology.org/index.php/May_2007_Monthly_Report > > Enjoy! > > Rama > From jdeegan at ebi.ac.uk Thu Jun 7 07:21:15 2007 From: jdeegan at ebi.ac.uk (Jennifer Deegan (nee Clark)) Date: Thu, 07 Jun 2007 15:21:15 +0100 Subject: [go] transporter activity Message-ID: <4668145B.2070206@ebi.ac.uk> Hi, The transporter activity working group have been working for some weeks to improve the function terms under transporter activity. We have now made all of the major changes in a draft file, and we are planning to make this live and then make the remaining changes in the live file. You can view the latest version of the draft file here: http://cvsweb.geneontology.org/cgi-bin/cvsweb.cgi/go/scratch/transport.obo The minutes of our meetings are all here: http://wiki.geneontology.org/index.php/Meeting_Notes The documentation for the new standard structure is here: http://wiki.geneontology.org/index.php/Docs The file will be committed on the 4th July. If you have any comments please do get in touch. Best wishes, Jennifer (On behalf of the transporter activity working group.) -- Jennifer Deegan (nee Clark) EMBL-European Bioinformatics Institute Gene Ontology Consortium From jane at ebi.ac.uk Thu Jun 7 09:42:20 2007 From: jane at ebi.ac.uk (Jane Lomax) Date: Thu, 07 Jun 2007 17:42:20 +0100 Subject: [go] transporter activity In-Reply-To: <4668145B.2070206@ebi.ac.uk> References: <4668145B.2070206@ebi.ac.uk> Message-ID: <4668356C.6070106@ebi.ac.uk> Looks great Jen - well done to all those that worked on this! A couple of queries: Why aren't all of the "x-substrate transporters" e.g. 'biotin transporter activity' children of 'substrate-specific transporter'? Is 'intracellular transporter' still a useful term to keep? Presumably lots of the transmembrane transporters are intracellular, so seems a bit counter-intuitive. Could this be changed to 'soluble transporter' or something? (trying not to use "non-membrane"!) Were you planning to obsolete 'xenobiotic transporter activity'? Jane Jennifer Deegan (nee Clark) wrote: > Hi, > > The transporter activity working group have been working for some > weeks to improve the function terms under transporter activity. We > have now made all of the major changes in a draft file, and we are > planning to make this live and then make the remaining changes in the > live file. > > You can view the latest version of the draft file here: > > http://cvsweb.geneontology.org/cgi-bin/cvsweb.cgi/go/scratch/transport.obo > > > The minutes of our meetings are all here: > > http://wiki.geneontology.org/index.php/Meeting_Notes > > The documentation for the new standard structure is here: > > http://wiki.geneontology.org/index.php/Docs > > The file will be committed on the 4th July. If you have any comments > please do get in touch. > > Best wishes, > > Jennifer > > (On behalf of the transporter activity working group.) > > From rama at genome.Stanford.EDU Thu Jun 7 10:31:00 2007 From: rama at genome.Stanford.EDU (Rama Balakrishnan) Date: Thu, 7 Jun 2007 10:31:00 -0700 Subject: [go] May annotation outreach report In-Reply-To: <856F80F4-8A38-4A51-9F85-AEF39F520FC2@gen.cam.ac.uk> References: <7A17E3B1-3FEC-4843-B84C-90BA0590E469@genome.stanford.edu> <856F80F4-8A38-4A51-9F85-AEF39F520FC2@gen.cam.ac.uk> Message-ID: <5A0A0CA9-0669-4C13-BA24-8501686405AB@genome.stanford.edu> Michael, Thanks for your comments. We will try to keep it less-garish. I think the flow chart is still crude. We will let you know when it is ready for comments from the larger GO group. Best, Rama On Jun 6, 2007, at 1:20 AM, Michael Ashburner wrote: > Do you want detailed comments on flow charts yet, or latter ? > Look good, but in general I suggest a very conservative use of colors > and keep these non-garish ! > > Michael > > On 5 Jun 2007, at 21:37, Rama Balakrishnan wrote: > >> Hi All, >> >> The outreach working group report for the month of May is >> available on the Wiki- >> >> http://gocwiki.geneontology.org/index.php/May_2007_Monthly_Report >> >> Enjoy! >> >> Rama >> From val at sanger.ac.uk Fri Jun 8 05:00:06 2007 From: val at sanger.ac.uk (Valerie Wood) Date: Fri, 08 Jun 2007 13:00:06 +0100 Subject: [go] transporter activity In-Reply-To: <4668356C.6070106@ebi.ac.uk> References: <4668145B.2070206@ebi.ac.uk> <4668356C.6070106@ebi.ac.uk> Message-ID: <466944C6.1010808@sanger.ac.uk> Jane Lomax wrote: > Looks great Jen - well done to all those that worked on this! > > A couple of queries: > > Why aren't all of the "x-substrate transporters" e.g. 'biotin > transporter activity' children of 'substrate-specific transporter'? We must have missed these, they should be. > > Is 'intracellular transporter' still a useful term to keep? Presumably > lots of the transmembrane transporters are intracellular, so seems a > bit counter-intuitive. Could this be changed to 'soluble transporter' > or something? (trying not to use "non-membrane"!) I think you're right Jane, i don't think we need this term.It looks as though think it was there as a parent for these odd terms, which I think have been mostly moved or obsoleted GO:0005487: nucleocytoplasmic transporter activity GO:0005484: SNAP receptor activity (now under protein binding) GO:0005483: soluble NSF attachment protein activity (now under protein binding) GO:0015447: type II protein secretor activity VAl > > Were you planning to obsolete 'xenobiotic transporter activity'? > > Jane > > > Jennifer Deegan (nee Clark) wrote: > >> Hi, >> >> The transporter activity working group have been working for some >> weeks to improve the function terms under transporter activity. We >> have now made all of the major changes in a draft file, and we are >> planning to make this live and then make the remaining changes in the >> live file. >> >> You can view the latest version of the draft file here: >> >> http://cvsweb.geneontology.org/cgi-bin/cvsweb.cgi/go/scratch/transport.obo >> >> >> The minutes of our meetings are all here: >> >> http://wiki.geneontology.org/index.php/Meeting_Notes >> >> The documentation for the new standard structure is here: >> >> http://wiki.geneontology.org/index.php/Docs >> >> The file will be committed on the 4th July. If you have any comments >> please do get in touch. >> >> Best wishes, >> >> Jennifer >> >> (On behalf of the transporter activity working group.) >> >> > > -- The Wellcome Trust Sanger Institute is operated by Genome Research Limited, a charity registered in England with number 1021457 and a company registered in England with number 2742969, whose registered office is 215 Euston Road, London, NW1 2BE. From val at sanger.ac.uk Fri Jun 8 14:45:16 2007 From: val at sanger.ac.uk (Valerie Wood) Date: Fri, 8 Jun 2007 21:45:16 UT Subject: [go] Re: A quick question Message-ID: An embedded and charset-unspecified text was scrubbed... Name: not available Url: http://fafner.stanford.edu/pipermail/go/attachments/20070608/4e24e932/attachment.pl From suzi at berkeleybop.org Sat Jun 9 16:01:04 2007 From: suzi at berkeleybop.org (Suzanna Lewis) Date: Sat, 9 Jun 2007 16:01:04 -0700 Subject: [go] GO managers minutes: June 6, 2007 Message-ID: <70AA7C96-49FC-4170-8AC2-7E8EA093F114@berkeleybop.org> The minutes from the last GO manager's meeting are now on the wiki: http://gocwiki.geneontology.org/index.php/Managers_6Jun07 If you would like a particular issue to be discussed at the next managers' call, please contact the relevant manager(s): Reference Genomes: Rex User Advocacy: Jane and Eurie Content Development: Midori and David Annotation Outreach: Jennifer Software: Chris For general management and budget issues, contact the GO PIs . From suzi at berkeleybop.org Sat Jun 9 16:18:29 2007 From: suzi at berkeleybop.org (Suzanna Lewis) Date: Sat, 9 Jun 2007 16:18:29 -0700 Subject: [go] May annotation outreach report In-Reply-To: <7A17E3B1-3FEC-4843-B84C-90BA0590E469@genome.stanford.edu> References: <7A17E3B1-3FEC-4843-B84C-90BA0590E469@genome.stanford.edu> Message-ID: <7F52C967-9AF5-4813-B90E-CDF0C4EDEFBB@berkeleybop.org> Hi Rama, Who all is working on the flowchart? I was thinking that it might be useful to get feedback from some of the groups who have recently been through this process (like Fiona). But maybe you already have? -S On Jun 5, 2007, at 1:37 PM, Rama Balakrishnan wrote: > Hi All, > > The outreach working group report for the month of May is available > on the Wiki- > > http://gocwiki.geneontology.org/index.php/May_2007_Monthly_Report > > Enjoy! > > Rama > > From rama at genome.Stanford.EDU Sat Jun 9 22:55:36 2007 From: rama at genome.Stanford.EDU (Rama Balakrishnan) Date: Sat, 9 Jun 2007 22:55:36 -0700 Subject: [go] May annotation outreach report In-Reply-To: <7F52C967-9AF5-4813-B90E-CDF0C4EDEFBB@berkeleybop.org> References: <7A17E3B1-3FEC-4843-B84C-90BA0590E469@genome.stanford.edu> <7F52C967-9AF5-4813-B90E-CDF0C4EDEFBB@berkeleybop.org> Message-ID: Suzi, Yes we have. Fiona is in the outreach group and participates in the conference calls. She has contributed a lot to these flowcharts. rama On Jun 9, 2007, at 4:18 PM, Suzanna Lewis wrote: > Hi Rama, > > Who all is working on the flowchart? I was thinking that it might > be useful to get feedback from some of the groups who have recently > been through this process (like Fiona). But maybe you already have? > > -S > > On Jun 5, 2007, at 1:37 PM, Rama Balakrishnan wrote: > >> Hi All, >> >> The outreach working group report for the month of May is >> available on the Wiki- >> >> http://gocwiki.geneontology.org/index.php/May_2007_Monthly_Report >> >> Enjoy! >> >> Rama >> >> From jane at ebi.ac.uk Mon Jun 11 04:17:03 2007 From: jane at ebi.ac.uk (Jane Lomax) Date: Mon, 11 Jun 2007 12:17:03 +0100 Subject: [go] Re: A quick question In-Reply-To: References: Message-ID: <466D2F2F.10805@ebi.ac.uk> Hi Val - They seem to be integrating data from a wide variety of sources - on their website it says: Different resources are available for download: * CCO Ontology (Data from: GO, RO, NCBI, GOA, UniProt, IntAct, in-house): o OBO format , o OWL format , o XML format , o DOT format , o GML format , o XGMML format (under development), o SBML format (under development). * CCO Ontology *per organism* (Data from: GO, RO, NCBI, GOA, UniProt, IntAct, in-house): o A. thaliana: OBO format , OWL format , XML format , DOT format , GML format . o S. cerevisiae: OBO format , OWL format , XML format , DOT format , GML format . o S. pombe: OBO format , OWL format , XML format , DOT format , GML format . o H. sapiens: OBO format , OWL format , XML format , DOT format , GML format . so they do cite GO, just not in the individual annotations...this is something we do internally, but not something we provide recommendations to external groups about, our citation policy just says "That the Gene Ontology Consortium is clearly acknowledged as the source of the product". I notice they're using OBO format rather than GA format - is there a field in OBO for 'source'? jane Valerie Wood wrote: > This looks OK to me, because it is the manual GO annotation with relationships added. > > A question for the consortium, shouldn't CCO recognise GO as the source of these annotaions? > It looks like they are independently created but they are the existing GO annotations mapped to CCO terms....... > > Do people think that It's slightly worrying that the source of the annotations is not clear to users ? > > Val > > > Saumyadipta Pyne wrote: > >> By the way, Val, a quick question: did you see the CCO annotation? >> What is your opinion about it, if you have looked at it? >> >> http://www.cellcycleontology.org/ontology/cco_S_pombe.obo >> http://www.cellcycleontology.org/ontology/cco_S_pombe.owl >> >> Thanks. >> -Pyne >> >> ------------------------------------------------------ >> Saumyadipta Pyne wrote: >> Hi Val, >> >> I am trying to use 'List download' at genedb/pombe/ >> for downloading Intergenic sequences for a list of genes >> pointed out to me by Jurg Bahler (attached), and I'm getting >> the following error. Could you please possibly tell me >> what I am doing wrong here? >> >> Thanks much. >> -Pyne >> >> > > From ma11 at gen.cam.ac.uk Mon Jun 11 04:52:20 2007 From: ma11 at gen.cam.ac.uk (Michael Ashburner (Genetics)) Date: Mon, 11 Jun 2007 12:52:20 +0100 Subject: [go] Re: A quick question Message-ID: Does anyone know these people ? Do we have any interactions with them ? Are their obo2owl and owl2obo parsers new s/ware they developed ? Michael From jane at ebi.ac.uk Mon Jun 11 05:35:29 2007 From: jane at ebi.ac.uk (Jane Lomax) Date: Mon, 11 Jun 2007 13:35:29 +0100 (BST) Subject: [go] Re: A quick question In-Reply-To: References: Message-ID: I met them at a workshop in Ghent a couple of weeks ago - they had a load of suggested changes to the cell cycle node that I submitted to SF for them. Their obo/owl parsers are not their own, although I think they contributed to the development of the new mapping... jane On Mon, 11 Jun 2007, Michael Ashburner wrote: > Does anyone know these people ? Do we have any interactions with them ? > Are their obo2owl and owl2obo parsers new s/ware they developed ? > > Michael > Dr Jane Lomax GO Editorial Office EMBL-EBI Wellcome Trust Genome Campus Hinxton Cambridgeshire, UK CB10 1SD p: +44 1223 492516 f: +44 1223 494468 From ma11 at gen.cam.ac.uk Mon Jun 11 05:53:31 2007 From: ma11 at gen.cam.ac.uk (Michael Ashburner (Genetics)) Date: Mon, 11 Jun 2007 13:53:31 +0100 Subject: [go] Re: A quick question Message-ID: Ah, they are the guys you mentioned. Good, so we are in contact with them. What I do not see is any xref of their terms to GO terms, eg: relationship: located_in CCO:C0000251 ! nucleus and : relationship: located_in CCO:C0000548 ! proteasome regulatory particle, base subcomplex (sensu Eukaryota) are presumably GO terms with their CCO ids. Michael From jane at ebi.ac.uk Mon Jun 11 06:55:22 2007 From: jane at ebi.ac.uk (Jane Lomax) Date: Mon, 11 Jun 2007 14:55:22 +0100 (BST) Subject: [go] Re: A quick question In-Reply-To: References: Message-ID: Yes, I see what you mean...I'll bring this up with them... jane On Mon, 11 Jun 2007, Michael Ashburner wrote: > Ah, they are the guys you mentioned. Good, so we are in contact with them. > What I do not see is any xref of their terms to GO terms, > eg: relationship: located_in CCO:C0000251 ! nucleus > and : relationship: located_in CCO:C0000548 ! proteasome regulatory particle, base subcomplex (sensu Eukaryota) > are presumably GO terms with their CCO ids. > > Michael > Dr Jane Lomax GO Editorial Office EMBL-EBI Wellcome Trust Genome Campus Hinxton Cambridgeshire, UK CB10 1SD p: +44 1223 492516 f: +44 1223 494468 From ma11 at gen.cam.ac.uk Tue Jun 12 08:18:22 2007 From: ma11 at gen.cam.ac.uk (Michael Ashburner (Genetics)) Date: Tue, 12 Jun 2007 16:18:22 +0100 Subject: [go] for Outreach Message-ID: Eurie/Jane I wonder whether or not the existence of the Cambridge Minutes should be a GO New item on the front page ? Michael From jane at ebi.ac.uk Tue Jun 12 09:35:29 2007 From: jane at ebi.ac.uk (Jane Lomax) Date: Tue, 12 Jun 2007 17:35:29 +0100 Subject: [go] for Outreach In-Reply-To: References: Message-ID: <466ECB51.6090904@ebi.ac.uk> Yep - I'll add... jane Michael Ashburner (Genetics) wrote: > Eurie/Jane > > I wonder whether or not the existence of the Cambridge Minutes should be > a GO New item on the front page ? > Michael > From pj37 at cornell.edu Wed Jun 13 10:12:46 2007 From: pj37 at cornell.edu (Pankaj Jaiswal) Date: Wed, 13 Jun 2007 13:12:46 -0400 Subject: [go] Guide to GO Evidence Codes Message-ID: <4670258E.2070109@cornell.edu> in the IEA section it says If the method is match-based (e.g., uses sequence comparisons), a valid database ID must entered in the with column. A with column entry is not mandatory for non-match-based methods. What is the mechanism on storing the method and making sure what is mandatory? We are trying to load the annotations to the cvs that are coming prom the prediction using Signal/TargetP and TMHMMs and they do not qualify sequence matching criteria. The mandatory rule stated above is rejecting the annotations. Any suggestions? Pankaj From cherry at stanford.edu Wed Jun 13 10:39:58 2007 From: cherry at stanford.edu (Mike Cherry) Date: Wed, 13 Jun 2007 10:39:58 -0700 Subject: [go] Guide to GO Evidence Codes In-Reply-To: <4670258E.2070109@cornell.edu> References: <4670258E.2070109@cornell.edu> Message-ID: <6EF970C2-30E9-444A-AB44-8AC818BDCCFD@stanford.edu> See the email tread below from GOHELP. The IEA documentation is out of date. Something is required in the WITH field for all IEA and ISS. -Mike On Jun 13, 2007, at 10:12 AM, Pankaj Jaiswal wrote: > > > > in the IEA section it says > > If the method is match-based (e.g., uses sequence comparisons), a > valid database ID must entered in the with column. A with column > entry is not mandatory for non-match-based methods. > > > What is the mechanism on storing the method and making sure what is > mandatory? We are trying to load the annotations to the cvs that > are coming prom the prediction using Signal/TargetP and TMHMMs and > they do not qualify sequence matching criteria. The mandatory rule > stated above is rejecting the annotations. > > Any suggestions? > > Pankaj Begin forwarded message: > From: Mike Cherry > Date: June 8, 2007 10:22:15 AM PDT > To: Maria Costanzo > Cc: Midori Harris , David Hill > , gohelp > Subject: Re: [gohelp] Re: [Fwd: GO Help query (from website)] > > Yes. That was most of the debate, what should be in the WITH > column and was it okay to have things other than sequences. In the > end we went for just having something instead of trying to trying > to decide how we would know the difference between different types > of IEA. > > -Mike > > > On Jun 8, 2007, at 10:15 AM, Maria Costanzo wrote: > >> So, the 'with' column could contain either a reference number that >> refers to a method, or a database ID, as long as it contains >> something? >> >> Thanks, >> Maria >> >> On Jun 8, 2007, at 1:13 PM, Mike Cherry wrote: >> >>> It does not make a distinction. An IEA is an IEA for this. >>> >>> From page 15 of the Cambridge GOC minutes: >>> >>> Resolved: Always use a WITH column for IEA and ISS, containing a >>> program name if necessary. For example, make a ref to tRNAscan. >>> If an author says that that they used BLAST, but does not provide >>> the accession for the match, then use TAS code, not ISS. >>> >>> Noted: WITH column required for IEA in 4 months. >>> >>> >>> -Mike >>> >>> >>> >>> On Jun 8, 2007, at 9:53 AM, Maria Costanzo wrote: >>> >>>> Thanks to both of you. My most immediate question is, what >>>> exactly does the filtering script currently look for and how >>>> does it distinguish between 'match-based' and 'non-match-based' >>>> IEAs? >>>> >>>> Thanks, >>>> Maria >>>> >>>> >>>> On Jun 8, 2007, at 12:48 PM, Midori Harris wrote: >>>> >>>>> Ironically, that's one of the most recently updated parts of >>>>> the evidence code document, since it reflects the decision from >>>>> the 2006 St. Croix meeting (superseded at the last meeting, but >>>>> without much detail). I must admit that I'm not sure what >>>>> should go in the 'with' column for methods not based on >>>>> matches; I thought the evidence code group would work that out. >>>>> >>>>> m >>>>> >>>>> On Fri, 8 Jun 2007, Mike Cherry wrote: >>>>> >>>>>> It is my understanding that the WITH column is required for >>>>>> all IEA annotations made after May 1, 2007. At least that is >>>>>> what the filtering script is doing. This was discussed at the >>>>>> Jesus College meeting. >>>>>> >>>>>> Thus the documentation is out of date. >>>>>> >>>>>> The evidence code group needs to be pushed to get their act >>>>>> together. They have been meeting for at least nine months and >>>>>> there has not been an update. I propose that the evidence code >>>>>> group be disbanded and someone that will actually do the work >>>>>> be put in charge. >>>>>> >>>>>> -Mike >>>>>> >>>>>> >>>>>> On Jun 8, 2007, at 5:15 AM, David Hill wrote: >>>>>> >>>>>>> Hi Mike, >>>>>>> Can you help Maria with this question that came into GO help? >>>>>>> Thanks, >>>>>>> David >>>>>>> -------- Original Message -------- >>>>>>> Subject: GO Help query (from website) >>>>>>> Date: Thu, 7 Jun 2007 17:07:16 -0700 (PDT) >>>>>>> From: noreply at genome.stanford.edu >>>>>>> To: maria at genome.stanford.edu >>>>>>> contactName: Maria Costanzo >>>>>>> contactEmail: maria at genome.stanford.edu >>>>>>> contactText: Hi, >>>>>>> I'm wearing my CGD hat rather than my SGD hat right now. Some >>>>>>> rows were >>>>>>> removed from our CGD gene_association file by the filtering >>>>>>> script because >>>>>>> they had IEA evidence, were made after May 1 2007, and didn't >>>>>>> have a >>>>>>> database ID in the 'with' column. The IEA documentation says: >>>>>>> If the method is match-based (e.g., uses sequence >>>>>>> comparisons), a valid >>>>>>> database ID must entered in the with column. A with column >>>>>>> entry is not >>>>>>> mandatory for non-match-based methods. >>>>>>> So, I have a couple of questions: >>>>>>> 1. The documentation on the error checking script >>>>>>> http://www.geneontology.org/GO.format.annotation.shtml#script >>>>>>> doesn't mention this new filtering step. It would be great if >>>>>>> you could >>>>>>> update that. >>>>>>> 2. How does the script distinguish between 'match-based' and >>>>>>> 'non-match-based' annotations? >>>>>>> Thanks, >>>>>>> Maria >>>>>> > From pj37 at cornell.edu Wed Jun 13 11:23:01 2007 From: pj37 at cornell.edu (Pankaj Jaiswal) Date: Wed, 13 Jun 2007 14:23:01 -0400 Subject: [go] Guide to GO Evidence Codes In-Reply-To: <6EF970C2-30E9-444A-AB44-8AC818BDCCFD@stanford.edu> References: <4670258E.2070109@cornell.edu> <6EF970C2-30E9-444A-AB44-8AC818BDCCFD@stanford.edu> Message-ID: <46703605.9090708@cornell.edu> I see the thread, but I don't understand this 'something'. We have predictions from TargetP and TMHMMs that if meet a certain higher cutoff get the RCAs because we trust those with higher confidence. Rest goes as IEAs but still with a known cutoff. Its not like winner takes all. So we have an internal protocol on how we select. This does not refer to a generic method or a PMID for these tools. I suggest until there is a resolution on what is specifically this 'something' is, the mandatory rule be released. Pankaj Mike Cherry wrote: > See the email tread below from GOHELP. The IEA documentation is out of > date. Something is required in the WITH field for all IEA and ISS. > > -Mike > > > > On Jun 13, 2007, at 10:12 AM, Pankaj Jaiswal wrote: > >> >> >> >> in the IEA section it says >> >> If the method is match-based (e.g., uses sequence comparisons), a >> valid database ID must entered in the with column. A with column entry >> is not mandatory for non-match-based methods. >> >> >> What is the mechanism on storing the method and making sure what is >> mandatory? We are trying to load the annotations to the cvs that are >> coming prom the prediction using Signal/TargetP and TMHMMs and they do >> not qualify sequence matching criteria. The mandatory rule stated >> above is rejecting the annotations. >> >> Any suggestions? >> >> Pankaj > > > > > Begin forwarded message: >> From: Mike Cherry >> Date: June 8, 2007 10:22:15 AM PDT >> To: Maria Costanzo >> Cc: Midori Harris , David Hill >> , gohelp >> Subject: Re: [gohelp] Re: [Fwd: GO Help query (from website)] >> >> Yes. That was most of the debate, what should be in the WITH column >> and was it okay to have things other than sequences. In the end we >> went for just having something instead of trying to trying to decide >> how we would know the difference between different types of IEA. >> >> -Mike >> >> >> On Jun 8, 2007, at 10:15 AM, Maria Costanzo wrote: >> >>> So, the 'with' column could contain either a reference number that >>> refers to a method, or a database ID, as long as it contains something? >>> >>> Thanks, >>> Maria >>> >>> On Jun 8, 2007, at 1:13 PM, Mike Cherry wrote: >>> >>>> It does not make a distinction. An IEA is an IEA for this. >>>> >>>> From page 15 of the Cambridge GOC minutes: >>>> >>>> Resolved: Always use a WITH column for IEA and ISS, containing a >>>> program name if necessary. For example, make a ref to tRNAscan. If >>>> an author says that that they used BLAST, but does not provide the >>>> accession for the match, then use TAS code, not ISS. >>>> >>>> Noted: WITH column required for IEA in 4 months. >>>> >>>> >>>> -Mike >>>> >>>> >>>> >>>> On Jun 8, 2007, at 9:53 AM, Maria Costanzo wrote: >>>> >>>>> Thanks to both of you. My most immediate question is, what exactly >>>>> does the filtering script currently look for and how does it >>>>> distinguish between 'match-based' and 'non-match-based' IEAs? >>>>> >>>>> Thanks, >>>>> Maria >>>>> >>>>> >>>>> On Jun 8, 2007, at 12:48 PM, Midori Harris wrote: >>>>> >>>>>> Ironically, that's one of the most recently updated parts of the >>>>>> evidence code document, since it reflects the decision from the >>>>>> 2006 St. Croix meeting (superseded at the last meeting, but >>>>>> without much detail). I must admit that I'm not sure what should >>>>>> go in the 'with' column for methods not based on matches; I >>>>>> thought the evidence code group would work that out. >>>>>> >>>>>> m >>>>>> >>>>>> On Fri, 8 Jun 2007, Mike Cherry wrote: >>>>>> >>>>>>> It is my understanding that the WITH column is required for all >>>>>>> IEA annotations made after May 1, 2007. At least that is what >>>>>>> the filtering script is doing. This was discussed at the Jesus >>>>>>> College meeting. >>>>>>> >>>>>>> Thus the documentation is out of date. >>>>>>> >>>>>>> The evidence code group needs to be pushed to get their act >>>>>>> together. They have been meeting for at least nine months and >>>>>>> there has not been an update. I propose that the evidence code >>>>>>> group be disbanded and someone that will actually do the work be >>>>>>> put in charge. >>>>>>> >>>>>>> -Mike >>>>>>> >>>>>>> >>>>>>> On Jun 8, 2007, at 5:15 AM, David Hill wrote: >>>>>>> >>>>>>>> Hi Mike, >>>>>>>> Can you help Maria with this question that came into GO help? >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> -------- Original Message -------- >>>>>>>> Subject: GO Help query (from website) >>>>>>>> Date: Thu, 7 Jun 2007 17:07:16 -0700 (PDT) >>>>>>>> From: noreply at genome.stanford.edu >>>>>>>> To: maria at genome.stanford.edu >>>>>>>> contactName: Maria Costanzo >>>>>>>> contactEmail: maria at genome.stanford.edu >>>>>>>> contactText: Hi, >>>>>>>> I'm wearing my CGD hat rather than my SGD hat right now. Some >>>>>>>> rows were >>>>>>>> removed from our CGD gene_association file by the filtering >>>>>>>> script because >>>>>>>> they had IEA evidence, were made after May 1 2007, and didn't >>>>>>>> have a >>>>>>>> database ID in the 'with' column. The IEA documentation says: >>>>>>>> If the method is match-based (e.g., uses sequence comparisons), >>>>>>>> a valid >>>>>>>> database ID must entered in the with column. A with column entry >>>>>>>> is not >>>>>>>> mandatory for non-match-based methods. >>>>>>>> So, I have a couple of questions: >>>>>>>> 1. The documentation on the error checking script >>>>>>>> http://www.geneontology.org/GO.format.annotation.shtml#script >>>>>>>> doesn't mention this new filtering step. It would be great if >>>>>>>> you could >>>>>>>> update that. >>>>>>>> 2. How does the script distinguish between 'match-based' and >>>>>>>> 'non-match-based' annotations? >>>>>>>> Thanks, >>>>>>>> Maria >>>>>>> >> > > > > -- Pankaj Jaiswal G-15, Bradfield Hall Dept. of Plant Breeding and Genetics Cornell University Ithaca, NY-14853, USA Ph. +1-607-255-3103 / 4199 fax: +1-607-255-6683 From cherry at stanford.edu Wed Jun 13 12:48:51 2007 From: cherry at stanford.edu (Mike Cherry) Date: Wed, 13 Jun 2007 12:48:51 -0700 Subject: [go] Guide to GO Evidence Codes In-Reply-To: <46703605.9090708@cornell.edu> References: <4670258E.2070109@cornell.edu> <6EF970C2-30E9-444A-AB44-8AC818BDCCFD@stanford.edu> <46703605.9090708@cornell.edu> Message-ID: <9A429518-E524-4CF7-A794-709F73426EAB@stanford.edu> The rule as you call it was agreed to in January and the filtering script changed. You just have to put some text (something if you like) in the WITH field. -mike On Jun 13, 2007, at 11:23 AM, Pankaj Jaiswal wrote: > I see the thread, but I don't understand this 'something'. We have > predictions from TargetP and TMHMMs that if meet a certain higher > cutoff get the RCAs because we trust those with higher confidence. > Rest goes as IEAs but still with a known cutoff. Its not like > winner takes all. So we have an internal protocol on how we select. > This does not refer to a generic method or a PMID for these tools. > > I suggest until there is a resolution on what is specifically this > 'something' is, the mandatory rule be released. > > Pankaj > > Mike Cherry wrote: >> See the email tread below from GOHELP. The IEA documentation is >> out of date. Something is required in the WITH field for all IEA >> and ISS. >> -Mike >> On Jun 13, 2007, at 10:12 AM, Pankaj Jaiswal wrote: >>> >>> >>> >>> in the IEA section it says >>> >>> If the method is match-based (e.g., uses sequence comparisons), a >>> valid database ID must entered in the with column. A with column >>> entry is not mandatory for non-match-based methods. >>> >>> >>> What is the mechanism on storing the method and making sure what >>> is mandatory? We are trying to load the annotations to the cvs >>> that are coming prom the prediction using Signal/TargetP and >>> TMHMMs and they do not qualify sequence matching criteria. The >>> mandatory rule stated above is rejecting the annotations. >>> >>> Any suggestions? >>> >>> Pankaj >> Begin forwarded message: >>> From: Mike Cherry >>> Date: June 8, 2007 10:22:15 AM PDT >>> To: Maria Costanzo >>> Cc: Midori Harris , David Hill >>> , gohelp >>> Subject: Re: [gohelp] Re: [Fwd: GO Help query (from website)] >>> >>> Yes. That was most of the debate, what should be in the WITH >>> column and was it okay to have things other than sequences. In >>> the end we went for just having something instead of trying to >>> trying to decide how we would know the difference between >>> different types of IEA. >>> >>> -Mike >>> >>> >>> On Jun 8, 2007, at 10:15 AM, Maria Costanzo wrote: >>> >>>> So, the 'with' column could contain either a reference number >>>> that refers to a method, or a database ID, as long as it >>>> contains something? >>>> >>>> Thanks, >>>> Maria >>>> >>>> On Jun 8, 2007, at 1:13 PM, Mike Cherry wrote: >>>> >>>>> It does not make a distinction. An IEA is an IEA for this. >>>>> >>>>> From page 15 of the Cambridge GOC minutes: >>>>> >>>>> Resolved: Always use a WITH column for IEA and ISS, containing >>>>> a program name if necessary. For example, make a ref to >>>>> tRNAscan. If an author says that that they used BLAST, but does >>>>> not provide the accession for the match, then use TAS code, not >>>>> ISS. >>>>> >>>>> Noted: WITH column required for IEA in 4 months. >>>>> >>>>> >>>>> -Mike >>>>> >>>>> >>>>> >>>>> On Jun 8, 2007, at 9:53 AM, Maria Costanzo wrote: >>>>> >>>>>> Thanks to both of you. My most immediate question is, what >>>>>> exactly does the filtering script currently look for and how >>>>>> does it distinguish between 'match-based' and 'non-match- >>>>>> based' IEAs? >>>>>> >>>>>> Thanks, >>>>>> Maria >>>>>> >>>>>> >>>>>> On Jun 8, 2007, at 12:48 PM, Midori Harris wrote: >>>>>> >>>>>>> Ironically, that's one of the most recently updated parts of >>>>>>> the evidence code document, since it reflects the decision >>>>>>> from the 2006 St. Croix meeting (superseded at the last >>>>>>> meeting, but without much detail). I must admit that I'm not >>>>>>> sure what should go in the 'with' column for methods not >>>>>>> based on matches; I thought the evidence code group would >>>>>>> work that out. >>>>>>> >>>>>>> m >>>>>>> >>>>>>> On Fri, 8 Jun 2007, Mike Cherry wrote: >>>>>>> >>>>>>>> It is my understanding that the WITH column is required for >>>>>>>> all IEA annotations made after May 1, 2007. At least that >>>>>>>> is what the filtering script is doing. This was discussed >>>>>>>> at the Jesus College meeting. >>>>>>>> >>>>>>>> Thus the documentation is out of date. >>>>>>>> >>>>>>>> The evidence code group needs to be pushed to get their act >>>>>>>> together. They have been meeting for at least nine months >>>>>>>> and there has not been an update. I propose that the >>>>>>>> evidence code group be disbanded and someone that will >>>>>>>> actually do the work be put in charge. >>>>>>>> >>>>>>>> -Mike >>>>>>>> >>>>>>>> >>>>>>>> On Jun 8, 2007, at 5:15 AM, David Hill wrote: >>>>>>>> >>>>>>>>> Hi Mike, >>>>>>>>> Can you help Maria with this question that came into GO help? >>>>>>>>> Thanks, >>>>>>>>> David >>>>>>>>> -------- Original Message -------- >>>>>>>>> Subject: GO Help query (from website) >>>>>>>>> Date: Thu, 7 Jun 2007 17:07:16 -0700 (PDT) >>>>>>>>> From: noreply at genome.stanford.edu >>>>>>>>> To: maria at genome.stanford.edu >>>>>>>>> contactName: Maria Costanzo >>>>>>>>> contactEmail: maria at genome.stanford.edu >>>>>>>>> contactText: Hi, >>>>>>>>> I'm wearing my CGD hat rather than my SGD hat right now. >>>>>>>>> Some rows were >>>>>>>>> removed from our CGD gene_association file by the filtering >>>>>>>>> script because >>>>>>>>> they had IEA evidence, were made after May 1 2007, and >>>>>>>>> didn't have a >>>>>>>>> database ID in the 'with' column. The IEA documentation says: >>>>>>>>> If the method is match-based (e.g., uses sequence >>>>>>>>> comparisons), a valid >>>>>>>>> database ID must entered in the with column. A with column >>>>>>>>> entry is not >>>>>>>>> mandatory for non-match-based methods. >>>>>>>>> So, I have a couple of questions: >>>>>>>>> 1. The documentation on the error checking script >>>>>>>>> http://www.geneontology.org/GO.format.annotation.shtml#script >>>>>>>>> doesn't mention this new filtering step. It would be great >>>>>>>>> if you could >>>>>>>>> update that. >>>>>>>>> 2. How does the script distinguish between 'match-based' and >>>>>>>>> 'non-match-based' annotations? >>>>>>>>> Thanks, >>>>>>>>> Maria >>>>>>>> >>> > > -- > Pankaj Jaiswal > G-15, Bradfield Hall > Dept. of Plant Breeding and Genetics > Cornell University > Ithaca, NY-14853, USA > > Ph. +1-607-255-3103 / 4199 > fax: +1-607-255-6683 From midori at ebi.ac.uk Thu Jun 14 04:34:52 2007 From: midori at ebi.ac.uk (Midori Harris) Date: Thu, 14 Jun 2007 12:34:52 +0100 (BST) Subject: [go] Guide to GO Evidence Codes In-Reply-To: <9A429518-E524-4CF7-A794-709F73426EAB@stanford.edu> References: <4670258E.2070109@cornell.edu> <6EF970C2-30E9-444A-AB44-8AC818BDCCFD@stanford.edu> <46703605.9090708@cornell.edu> <9A429518-E524-4CF7-A794-709F73426EAB@stanford.edu> Message-ID: I have updated this bit of the Evidence Code Guide, since the old version has caused some confusion lately. Midori On Wed, 13 Jun 2007, Mike Cherry wrote: > The rule as you call it was agreed to in January and the filtering script > changed. You just have to put some text (something if you like) in the WITH > field. -mike > > > > On Jun 13, 2007, at 11:23 AM, Pankaj Jaiswal wrote: > >> I see the thread, but I don't understand this 'something'. We have >> predictions from TargetP and TMHMMs that if meet a certain higher cutoff >> get the RCAs because we trust those with higher confidence. Rest goes as >> IEAs but still with a known cutoff. Its not like winner takes all. So we >> have an internal protocol on how we select. This does not refer to a >> generic method or a PMID for these tools. >> >> I suggest until there is a resolution on what is specifically this >> 'something' is, the mandatory rule be released. >> >> Pankaj >> >> Mike Cherry wrote: >>> See the email tread below from GOHELP. The IEA documentation is out of >>> date. Something is required in the WITH field for all IEA and ISS. >>> -Mike >>> On Jun 13, 2007, at 10:12 AM, Pankaj Jaiswal wrote: >>>> >>>> >>>> >>>> in the IEA section it says >>>> >>>> If the method is match-based (e.g., uses sequence comparisons), a valid >>>> database ID must entered in the with column. A with column entry is not >>>> mandatory for non-match-based methods. >>>> >>>> >>>> What is the mechanism on storing the method and making sure what is >>>> mandatory? We are trying to load the annotations to the cvs that are >>>> coming prom the prediction using Signal/TargetP and TMHMMs and they do >>>> not qualify sequence matching criteria. The mandatory rule stated above >>>> is rejecting the annotations. >>>> >>>> Any suggestions? >>>> >>>> Pankaj >>> Begin forwarded message: >>>> From: Mike Cherry >>>> Date: June 8, 2007 10:22:15 AM PDT >>>> To: Maria Costanzo >>>> Cc: Midori Harris , David Hill >>>> , gohelp >>>> Subject: Re: [gohelp] Re: [Fwd: GO Help query (from website)] >>>> >>>> Yes. That was most of the debate, what should be in the WITH column and >>>> was it okay to have things other than sequences. In the end we went for >>>> just having something instead of trying to trying to decide how we would >>>> know the difference between different types of IEA. >>>> >>>> -Mike >>>> >>>> >>>> On Jun 8, 2007, at 10:15 AM, Maria Costanzo wrote: >>>> >>>>> So, the 'with' column could contain either a reference number that >>>>> refers to a method, or a database ID, as long as it contains something? >>>>> >>>>> Thanks, >>>>> Maria >>>>> >>>>> On Jun 8, 2007, at 1:13 PM, Mike Cherry wrote: >>>>> >>>>>> It does not make a distinction. An IEA is an IEA for this. >>>>>> >>>>>> From page 15 of the Cambridge GOC minutes: >>>>>> >>>>>> Resolved: Always use a WITH column for IEA and ISS, containing a >>>>>> program name if necessary. For example, make a ref to tRNAscan. If an >>>>>> author says that that they used BLAST, but does not provide the >>>>>> accession for the match, then use TAS code, not ISS. >>>>>> >>>>>> Noted: WITH column required for IEA in 4 months. >>>>>> >>>>>> >>>>>> -Mike >>>>>> >>>>>> >>>>>> >>>>>> On Jun 8, 2007, at 9:53 AM, Maria Costanzo wrote: >>>>>> >>>>>>> Thanks to both of you. My most immediate question is, what exactly >>>>>>> does the filtering script currently look for and how does it >>>>>>> distinguish between 'match-based' and 'non-match-based' IEAs? >>>>>>> >>>>>>> Thanks, >>>>>>> Maria >>>>>>> >>>>>>> >>>>>>> On Jun 8, 2007, at 12:48 PM, Midori Harris wrote: >>>>>>> >>>>>>>> Ironically, that's one of the most recently updated parts of the >>>>>>>> evidence code document, since it reflects the decision from the 2006 >>>>>>>> St. Croix meeting (superseded at the last meeting, but without much >>>>>>>> detail). I must admit that I'm not sure what should go in the 'with' >>>>>>>> column for methods not based on matches; I thought the evidence code >>>>>>>> group would work that out. >>>>>>>> >>>>>>>> m >>>>>>>> >>>>>>>> On Fri, 8 Jun 2007, Mike Cherry wrote: >>>>>>>> >>>>>>>>> It is my understanding that the WITH column is required for all IEA >>>>>>>>> annotations made after May 1, 2007. At least that is what the >>>>>>>>> filtering script is doing. This was discussed at the Jesus College >>>>>>>>> meeting. >>>>>>>>> >>>>>>>>> Thus the documentation is out of date. >>>>>>>>> >>>>>>>>> The evidence code group needs to be pushed to get their act >>>>>>>>> together. They have been meeting for at least nine months and there >>>>>>>>> has not been an update. I propose that the evidence code group be >>>>>>>>> disbanded and someone that will actually do the work be put in >>>>>>>>> charge. >>>>>>>>> >>>>>>>>> -Mike >>>>>>>>> >>>>>>>>> >>>>>>>>> On Jun 8, 2007, at 5:15 AM, David Hill wrote: >>>>>>>>> >>>>>>>>>> Hi Mike, >>>>>>>>>> Can you help Maria with this question that came into GO help? >>>>>>>>>> Thanks, >>>>>>>>>> David >>>>>>>>>> -------- Original Message -------- >>>>>>>>>> Subject: GO Help query (from website) >>>>>>>>>> Date: Thu, 7 Jun 2007 17:07:16 -0700 (PDT) >>>>>>>>>> From: noreply at genome.stanford.edu >>>>>>>>>> To: maria at genome.stanford.edu >>>>>>>>>> contactName: Maria Costanzo >>>>>>>>>> contactEmail: maria at genome.stanford.edu >>>>>>>>>> contactText: Hi, >>>>>>>>>> I'm wearing my CGD hat rather than my SGD hat right now. Some rows >>>>>>>>>> were >>>>>>>>>> removed from our CGD gene_association file by the filtering script >>>>>>>>>> because >>>>>>>>>> they had IEA evidence, were made after May 1 2007, and didn't have >>>>>>>>>> a >>>>>>>>>> database ID in the 'with' column. The IEA documentation says: >>>>>>>>>> If the method is match-based (e.g., uses sequence comparisons), a >>>>>>>>>> valid >>>>>>>>>> database ID must entered in the with column. A with column entry is >>>>>>>>>> not >>>>>>>>>> mandatory for non-match-based methods. >>>>>>>>>> So, I have a couple of questions: >>>>>>>>>> 1. The documentation on the error checking script >>>>>>>>>> http://www.geneontology.org/GO.format.annotation.shtml#script >>>>>>>>>> doesn't mention this new filtering step. It would be great if you >>>>>>>>>> could >>>>>>>>>> update that. >>>>>>>>>> 2. How does the script distinguish between 'match-based' and >>>>>>>>>> 'non-match-based' annotations? >>>>>>>>>> Thanks, >>>>>>>>>> Maria >>>>>>>>> >>>> >> >> -- >> Pankaj Jaiswal >> G-15, Bradfield Hall >> Dept. of Plant Breeding and Genetics >> Cornell University >> Ithaca, NY-14853, USA >> >> Ph. +1-607-255-3103 / 4199 >> fax: +1-607-255-6683 From kchris at genome.Stanford.EDU Thu Jun 14 23:18:03 2007 From: kchris at genome.Stanford.EDU (Karen Christie) Date: Thu, 14 Jun 2007 23:18:03 -0700 (PDT) Subject: [go] draft of evidence code documentation Message-ID: Hi all, Mike asked me to send out the draft of new Evidence Code documentation as they are currently, url below, for comments from the group as a whole. http://www-dev.yeastgenome.org/draftGO/go/www/GO.evidence.new.shtml Comments are in red boxes. Most are minor, relating to formatting or needing info from someone to complete an example. However, note that there are a few issues remaining to be resolved. 1. How to actually put things in the with column when it is a method, rather than an ID and there is no corresponding database or namespace. 2. Requirement that ND be the only allowable evidence code for unknown annotations 3. usage of the RCA evidence code Your comments welcome, thanks, -Karen and the Evidence Code Committee From jane at ebi.ac.uk Fri Jun 15 03:41:22 2007 From: jane at ebi.ac.uk (Jane Lomax) Date: Fri, 15 Jun 2007 11:41:22 +0100 Subject: [go] draft of evidence code documentation In-Reply-To: References: Message-ID: <46726CD2.2020501@ebi.ac.uk> I was under the impression that we'd agreed 2. at the Jan meeting i.e. ND is now the only allowable evidence code for unknown annotations? Jane Karen Christie wrote: > Hi all, > > Mike asked me to send out the draft of new Evidence Code documentation > as they are currently, url below, for comments from the group as a whole. > > http://www-dev.yeastgenome.org/draftGO/go/www/GO.evidence.new.shtml > > Comments are in red boxes. Most are minor, relating to formatting or > needing info from someone to complete an example. > > However, note that there are a few issues remaining to be resolved. > > 1. How to actually put things in the with column when it is a method, > rather than an ID and there is no corresponding database or namespace. > > 2. Requirement that ND be the only allowable evidence code for unknown > annotations > > 3. usage of the RCA evidence code > > Your comments welcome, > > thanks, > > -Karen and the Evidence Code Committee > From midori at ebi.ac.uk Fri Jun 15 05:49:16 2007 From: midori at ebi.ac.uk (Midori Harris) Date: Fri, 15 Jun 2007 13:49:16 +0100 (BST) Subject: [go] draft of evidence code documentation In-Reply-To: References: Message-ID: Hi, > http://www-dev.yeastgenome.org/draftGO/go/www/GO.evidence.new.shtml It's great to see this document making the rounds, and a lot of it is in very good shape. Most of it might as well go live soon, without waiting for the RCA documentation to be resolved (can just include a note to the effect that the RCA section is sitll in need of expansion/revision/whatever). Responses and comments on things in red: > We should have documentation that explains GO_REF's and links to it > when we refer to them. Links can go to the existing GO References page: http://www.geneontology.org/cgi-bin/references.cgi I can write up a description (which will be brief; there's not an enormous amount to say) and give it to Amelia to be added to the blurb at the top of this page. The plain text file from which the web page is generated contains a brief description of the format, which could be HTMLified and also added to the blurb if it would be useful. > Do we allow things like ChEBI IDs in the with field? I would say yes. > any more positive examples for IMP?, e.g. phenotypic similarity Dredged up from email from January 2002 ... Erich Schwarz needed to know which code to use for "other mutations sharing a complex mutant phenotype syndrome with [a well-characterized mutant]." My comment at the time was: "The situation you've described is IMP, not IGI, because (if I understand correctly) you're looking at one mutation at a time. Comparing the phenotype of one mutation to that of another helps you interpret the meaning, but is not a kind of genetic interaction." I think this still holds. Erich provided some details of an example, which I can forward if you want. > Should we add a statement in the paragraph above to IGI, similar to > the one in IMP, about care in making annotations from gain of > function mutations ...? Sounds reasonable to me. > The Evidence Code Committee discussed the idea of making GO > annotations from Reactome entries. ... What does the full group feel > about the idea of allowing the ID for a database record, when such > exist, in the with field? I'm all for including annotations based on Reactome entries -- they have a well-developed curation system that deeply involves expert biologists, so the statements in their records are very reliable. I am not in favor of putting the Reactome ID in the with field for these annotations, however, because the Reactome entry does not modify or supplement the evidence; rather, the entry provides the evidence. GO would effectively be using a Recatome record as a source of information about a gene product, so it would make much more sense to put the Reactome ID in the reference field. For the more general database record case, it may be that I don't sufficiently understand what might go in a GO_REF (or equivalent), so I don't understand the rationale for allowing 'with' for NAS. For the case where the author infers one thing from another, using a GO ID in 'with' makes more sense, but I think it's not really necessary because the author (presumably) hasn't actually made any GO annotations, and hasn't stated observations or conclusions in terms of, well, GO terms. (Perhaps this will change some day!) Also, note that we have expressly disallowed the use of 'with' for NAS, so the script would have to be changed if the use of with-for-NAS is agreed. >> Even if an author states in a paper that there is no data available >> or nothing is known about the gene product in a particular GO >> aspect, annotation to the corresponding root node should be made >> with ND evidence code citing either the annotating group's internal >> reference or the GOC's reference on use of the ND evidence code, >> not a specific paper. > > I realize that we agreed to the above statement at the last GOC > meeting, but... > > The more I think about it, the more I'm uncomfortable with the > decision that we made that unknown annotations can only be made with > ND, especially since the reason stated to do so has nothing to do > with evidence, but is to help people better identify the unknown > annotations. I understand, and would add that it also loses the information that at the time of writing, the authors -- who are presumably pretty well informed about the genes/gene products they study --are aware of no relevant data. (Tho this concern is not as grave as that of overloading an evidence code.) Other comments: **Last paragraph of Introduction: Change "effect" to "affect" in "... will also effect the quality of the resulting annotation." **IDA & IMP: Does "over-expression" really need to be hyphenated? I've seen it unhyphenated more frequently; also, there's one unhyphenated occurrence in the document. **IMP: > mutation in gene B provides information about gene A being > annotated. For this type of experiment, use the IGI code. and IGI: > Inference about one gene drawn from the phenotype of a mutation in a > different gene I have always disagreed with this usage: I've argued that IMP would be more appropriate, because in the examples given, only one gene is mutated, so the "combination of alterations" criterion for IGI is not met. But it's an argument that I lost years ago. Oh well. **IGI examples: The statements "For this type of experiment, use the IGI Code" could be deleted -- they're redundant with the fact that the description appears in a list headed "where the IGI code should be used." **ISS & with col: > Note that there should be good evidence that the gene product(s) > placed in the with/from column actually has the activity, process, > etc. being annotated. Do we want to specifically say the "good evidence" should be *experimental* evidence? Would be consistent with the Ref Genome requirement, and good practice generally ... cheers, and thanks for all the work! midori From cherry at stanford.edu Sun Jun 17 17:29:05 2007 From: cherry at stanford.edu (Mike Cherry) Date: Sun, 17 Jun 2007 17:29:05 -0700 Subject: [go] systems down at Stanford Message-ID: Palo Alto was hit by a major blackout last night. The power was off for over two hours. As a result the computer room where the GO and SGD servers are located lost power until the UPS could be reset. The web pages, AmiGO, CVSWEB, and command line CVS are currently down. At the latest we should have all the systems up by 10AM Monday morning Pacific time. -Mike From suzi at berkeleybop.org Sun Jun 17 14:04:06 2007 From: suzi at berkeleybop.org (Suzanna Lewis) Date: Sun, 17 Jun 2007 14:04:06 -0700 Subject: [go] web site down? Message-ID: <07D8E8F8-C2A6-403B-8344-E13E682079AB@berkeleybop.org> Don't know if anyone is around today, or if this is a temporary situation that I should already be aware of... but in case not, it is sunday, june 17, and I cannot get to either geneontology.org or the wiki. -S From val at sanger.ac.uk Mon Jun 18 06:43:31 2007 From: val at sanger.ac.uk (Valerie Wood) Date: Mon, 18 Jun 2007 14:43:31 +0100 Subject: [go] Estimating the annotation error rateof curated GO database sequence annotations Message-ID: <46768C03.50602@sanger.ac.uk> Seen this? The authors make a large number of incorrect assumptions about how curated ISS annotations are made......and estimate an error rate of 28-30% Jones C., A. Brown & U. Baumann (2007): Estimating the annotation error rate of curated GO database sequence annotations. BMC Bioinformatics 8, 170-. http://www.biomedcentral.com/1471-2105/8/170 -- The Wellcome Trust Sanger Institute is operated by Genome Research Limited, a charity registered in England with number 1021457 and a company registered in England with number 2742969, whose registered office is 215 Euston Road, London, NW1 2BE. From camon at ebi.ac.uk Mon Jun 18 07:01:25 2007 From: camon at ebi.ac.uk (camon at ebi.ac.uk) Date: Mon, 18 Jun 2007 15:01:25 +0100 (BST) Subject: [go] Estimating the annotation error rateof curated GO database sequence annotations In-Reply-To: <46768C03.50602@sanger.ac.uk> References: <46768C03.50602@sanger.ac.uk> Message-ID: <41192.86.145.107.65.1182175285.squirrel@webmail.ebi.ac.uk> Hi Yes Val, we saw that (infact I reviewed it)..I explained to the author that we(GOA) were removing all ISS go annotations which came from data with non-experimental code and that we were now using ensembl compara for automatic annotation of one to one and apparent one-to-one orthologs...this i hope will clean up error rates in ISS..which are very difficult to maintain manually..so he needs to re-run his tests... I would love if he would a check on our IEA error rate :-))) Evelyn > > Seen this? > > The authors make a large number of incorrect assumptions about how > curated ISS annotations are made......and estimate an error rate of > 28-30% > > > Jones C., A. Brown & U. Baumann (2007): Estimating the annotation error > rate > > of curated GO database sequence annotations. BMC Bioinformatics 8, 170-. > > http://www.biomedcentral.com/1471-2105/8/170 > > > -- > The Wellcome Trust Sanger Institute is operated by Genome Research > Limited, a charity registered in England with number 1021457 and a > company registered in England with number 2742969, whose registered > office is 215 Euston Road, London, NW1 2BE. > From val at sanger.ac.uk Mon Jun 18 07:55:17 2007 From: val at sanger.ac.uk (Valerie Wood) Date: Mon, 18 Jun 2007 15:55:17 +0100 Subject: [go] Estimating the annotation error rateof curated GO database sequence annotations In-Reply-To: <46769054.8000201@ebi.ac.uk> References: <46768C03.50602@sanger.ac.uk> <46769054.8000201@ebi.ac.uk> Message-ID: <46769CD5.8030504@sanger.ac.uk> I only skim read the paper but my main concern was that they are making the assumption that GO curated ISS annotations are derived from top Blast hits? Although a more minor point would be that they don't reilise there are procedures in place to prevent transitive annotations (but these are newer). They are pointing out correctly,that it is frequently inaccurate to make an ISS from Blast (even from a Blast hit to a characterised gene), but their assumption appears to be that this is how GO curators make ISS annotations. I don't think any consortium member (or Uniprot) have ever made annotations directly from Blast have they? Most require robust ortholog predictions (followed up with more analysis if ambiguous), or detailed evaluation of protein family membership using domain organisation etc. ISS annotations also need to be evaluated in the context of protein copy number and species distribution, and more conservative (general) annotations made where appropriate. Alternatively, if an ISS comes from a paper, these are usually accompanied by a multiple alignment made with knowledge of the author of the ortholog/family members/ biological roles, so these are usually also not susceptible to the same errors as a pairwise Blast hit. I can't work out how they can estimate an error rate with the methods they used, because they don't appear to be aware of how the curated ISS annotations are made in the first place? Although maybe this is because I don't know what GOSeqLite is? I couldn't find anything when I searched the GO website for this and the only refs to it when I Google are this paper..... Val Jennifer Deegan (nee Clark) wrote: > That seems an awful lot like publishing a paper to point out that dogs > have four legs. Shouldn't people know that making an ISS from an ISS > is daft? It sounds to me ad if he is ranting about people outside the > consortium doing this rather than us doing it. > > Jen > > Valerie Wood wrote: > >> >> >> Seen this? >> >> The authors make a large number of incorrect assumptions about how >> curated ISS annotations are made......and estimate an error rate of >> 28-30% >> >> >> Jones C., A. Brown & U. Baumann (2007): Estimating the annotation >> error rate >> of curated GO database sequence annotations. BMC Bioinformatics 8, 170-. >> >> http://www.biomedcentral.com/1471-2105/8/170 >> >> > -- The Wellcome Trust Sanger Institute is operated by Genome Research Limited, a charity registered in England with number 1021457 and a company registered in England with number 2742969, whose registered office is 215 Euston Road, London, NW1 2BE. From camon at ebi.ac.uk Mon Jun 18 08:12:11 2007 From: camon at ebi.ac.uk (camon at ebi.ac.uk) Date: Mon, 18 Jun 2007 16:12:11 +0100 (BST) Subject: [go] Estimating the annotation error rateof curated GO database sequence annotations In-Reply-To: <46769CD5.8030504@sanger.ac.uk> References: <46768C03.50602@sanger.ac.uk> <46769054.8000201@ebi.ac.uk> <46769CD5.8030504@sanger.ac.uk> Message-ID: <54823.86.145.107.65.1182179531.squirrel@webmail.ebi.ac.uk> Hi Val, GO seq lite I believe has no IEA annotations ??? therefore lighter:-)) This paper was reviewed along time ago before very detailed discussions on improving ISS annotations. Admitedly I now realise that I only commented on how GOA was creating ISS annotations at the time(probably wrongly thought he was just considering the human go annotations) and we indeed did use blast hits, protein and gene names etc.. to create ISS assumptions(not considering synteny etc..). This was of course not ideal which is why we are now using ensembl compara(which is better than the way we manually did ISS). I think at least for human GO annotations where there is a huge number of publications out there for us to curate, at least our time is better spent on manual experimental coded annotations. cheers, Evelyn > > > I only skim read the paper but my main concern was that they are making > the assumption that GO curated ISS annotations are derived from top > Blast hits? > Although a more minor point would be that they don't reilise there are > procedures in place to prevent transitive annotations (but these are > newer). > > They are pointing out correctly,that it is frequently inaccurate to > make an ISS from Blast (even from a Blast hit to a characterised gene), > but their assumption appears to be that this is how GO curators make ISS > annotations. I don't think any consortium member (or Uniprot) have ever > made annotations directly from Blast have they? > > Most require robust ortholog predictions (followed up with more analysis > if ambiguous), or detailed evaluation of protein family membership using > domain organisation etc. ISS annotations also need to be evaluated in > the context of protein copy number and species distribution, and more > conservative (general) annotations made where appropriate. > Alternatively, if an ISS comes from a paper, these are usually > accompanied by a multiple alignment made with knowledge of the author of > the ortholog/family members/ biological roles, so these are usually also > not susceptible to the same errors as a pairwise Blast hit. > > I can't work out how they can estimate an error rate with the methods > they used, because they don't appear to be aware of how the curated ISS > annotations are made in the first place? > > Although maybe this is because I don't know what GOSeqLite is? > I couldn't find anything when I searched the GO website for this and the > only refs to it when I Google are this paper..... > > Val > > > > > > Jennifer Deegan (nee Clark) wrote: > >> That seems an awful lot like publishing a paper to point out that dogs >> have four legs. Shouldn't people know that making an ISS from an ISS >> is daft? It sounds to me ad if he is ranting about people outside the >> consortium doing this rather than us doing it. >> >> Jen >> >> Valerie Wood wrote: >> >>> >>> >>> Seen this? >>> >>> The authors make a large number of incorrect assumptions about how >>> curated ISS annotations are made......and estimate an error rate of >>> 28-30% >>> >>> >>> Jones C., A. Brown & U. Baumann (2007): Estimating the annotation >>> error rate >>> of curated GO database sequence annotations. BMC Bioinformatics 8, >>> 170-. >>> >>> http://www.biomedcentral.com/1471-2105/8/170 >>> >>> >> > > > > -- > The Wellcome Trust Sanger Institute is operated by Genome Research > Limited, a charity registered in England with number 1021457 and a > company registered in England with number 2742969, whose registered > office is 215 Euston Road, London, NW1 2BE. > From camon at ebi.ac.uk Mon Jun 18 08:32:21 2007 From: camon at ebi.ac.uk (camon at ebi.ac.uk) Date: Mon, 18 Jun 2007 16:32:21 +0100 (BST) Subject: [go] Estimating the annotation error rateof curated GO database sequence annotations In-Reply-To: <4676A26B.2050205@sanger.ac.uk> References: <46768C03.50602@sanger.ac.uk> <46769054.8000201@ebi.ac.uk> <46769CD5.8030504@sanger.ac.uk> <54823.86.145.107.65.1182179531.squirrel@webmail.ebi.ac.uk> <4676A26B.2050205@sanger.ac.uk> Message-ID: <51902.86.145.107.65.1182180741.squirrel@webmail.ebi.ac.uk> Yes it would be nice to have an evaluation on a per MOD basis.. Evelyn > Ah I see....probably lots of things have changed since the paper was > reviewed.... > > A lot of my community use the ISS annotations to direct their > experiments, so I *hope* they don't have a 28-30% error rate ;) I would > get blasted ! > > Val > > > camon at ebi.ac.uk wrote: > >>Hi Val, >> >>GO seq lite I believe has no IEA annotations ??? therefore lighter:-)) >> >>This paper was reviewed along time ago before very detailed discussions >> on >>improving ISS annotations. Admitedly I now realise that I only commented >>on how GOA was creating ISS annotations at the time(probably wrongly >>thought he was just considering the human go annotations) and we indeed >>did use blast hits, protein and gene names etc.. to create ISS >>assumptions(not considering synteny etc..). This was of course not ideal >>which is why we are now using ensembl compara(which is better than the >> way >>we manually did ISS). I think at least for human GO annotations where >>there is a huge number of publications out there for us to curate, at >>least our time is better spent on manual experimental coded annotations. >> >>cheers, >> >>Evelyn >> >> >> >>>I only skim read the paper but my main concern was that they are making >>>the assumption that GO curated ISS annotations are derived from top >>>Blast hits? >>>Although a more minor point would be that they don't reilise there are >>>procedures in place to prevent transitive annotations (but these are >>>newer). >>> >>>They are pointing out correctly,that it is frequently inaccurate to >>>make an ISS from Blast (even from a Blast hit to a characterised gene), >>>but their assumption appears to be that this is how GO curators make ISS >>>annotations. I don't think any consortium member (or Uniprot) have ever >>>made annotations directly from Blast have they? >>> >>>Most require robust ortholog predictions (followed up with more analysis >>>if ambiguous), or detailed evaluation of protein family membership using >>>domain organisation etc. ISS annotations also need to be evaluated in >>>the context of protein copy number and species distribution, and more >>>conservative (general) annotations made where appropriate. >>>Alternatively, if an ISS comes from a paper, these are usually >>>accompanied by a multiple alignment made with knowledge of the author of >>>the ortholog/family members/ biological roles, so these are usually also >>>not susceptible to the same errors as a pairwise Blast hit. >>> >>>I can't work out how they can estimate an error rate with the methods >>>they used, because they don't appear to be aware of how the curated ISS >>>annotations are made in the first place? >>> >>>Although maybe this is because I don't know what GOSeqLite is? >>>I couldn't find anything when I searched the GO website for this and the >>>only refs to it when I Google are this paper..... >>> >>>Val >>> >>> >>> >>> >>> >>>Jennifer Deegan (nee Clark) wrote: >>> >>> >>> >>>>That seems an awful lot like publishing a paper to point out that dogs >>>>have four legs. Shouldn't people know that making an ISS from an ISS >>>>is daft? It sounds to me ad if he is ranting about people outside the >>>>consortium doing this rather than us doing it. >>>> >>>>Jen >>>> >>>>Valerie Wood wrote: >>>> >>>> >>>> >>>>>Seen this? >>>>> >>>>>The authors make a large number of incorrect assumptions about how >>>>>curated ISS annotations are made......and estimate an error rate of >>>>>28-30% >>>>> >>>>> >>>>>Jones C., A. Brown & U. Baumann (2007): Estimating the annotation >>>>>error rate >>>>>of curated GO database sequence annotations. BMC Bioinformatics 8, >>>>>170-. >>>>> >>>>>http://www.biomedcentral.com/1471-2105/8/170 >>>>> >>>>> >>>>> >>>>> >>> >>>-- >>>The Wellcome Trust Sanger Institute is operated by Genome Research >>>Limited, a charity registered in England with number 1021457 and a >>>company registered in England with number 2742969, whose registered >>>office is 215 Euston Road, London, NW1 2BE. >>> >>> >>> >> >> >> >> >> > > > > -- > The Wellcome Trust Sanger Institute is operated by Genome Research > Limited, a charity registered in England with number 1021457 and a > company registered in England with number 2742969, whose registered > office is 215 Euston Road, London, NW1 2BE. > From midori at ebi.ac.uk Mon Jun 18 09:01:01 2007 From: midori at ebi.ac.uk (Midori Harris) Date: Mon, 18 Jun 2007 17:01:01 +0100 (BST) Subject: [go] Alert: Proposal to obsolete GO:0015997 (function ontology) that impacts existing annotation Message-ID: Hello, The proposal has been made to obsolete ubiquinone biosynthetic process monooxygenase activity ; GO:0015997 There exist today annotations to this term as follows (not including IEA annotations): GeneDB_Spombe 1 DDB 1 FB 2 SGD 1 This term is not used in any GO slim set maintained within the OBO flat file. The term is used in external mappings: interpro2go: InterPro:IPR010971 Ubiquinone biosynthesis hydroxylase, UbiH/UbiF/VisC/COQ6 > GO:ubiquinone biosynthetic process monooxygenase activity ; GO:0015997 prosite2go: PROSITE:PS01304 UBIH > GO:ubiquinone biosynthetic process monooxygenase activity ; GO:0015997 The reason for this proposal is that it incorporates biological process information. Suggested terms to use to replace annotations: oxidoreductase activity, acting on paired donors, with incorporation or reduction of molecular oxygen, NADH or NADPH as one donor, and incorporation of one atom of oxygen ; GO:0016709 (is_a parent) ubiquinone biosynthetic process ; GO:0006744 Link to SourceForge discussion: https://sourceforge.net/tracker/?func=detail&atid=440764&aid=1739177&group_id=36855 The two-week comment period ends on Monday, July 2, 2007. Midori From camon at ebi.ac.uk Mon Jun 18 14:04:20 2007 From: camon at ebi.ac.uk (camon at ebi.ac.uk) Date: Mon, 18 Jun 2007 22:04:20 +0100 (BST) Subject: [go] Estimating the annotation error rateof curated GO database sequence annotations In-Reply-To: <51902.86.145.107.65.1182180741.squirrel@webmail.ebi.ac.uk> References: <46768C03.50602@sanger.ac.uk> <46769054.8000201@ebi.ac.uk> <46769CD5.8030504@sanger.ac.uk> <54823.86.145.107.65.1182179531.squirrel@webmail.ebi.ac.uk> <4676A26B.2050205@sanger.ac.uk> <51902.86.145.107.65.1182180741.squirrel@webmail.ebi.ac.uk> Message-ID: <43429.86.145.107.65.1182200660.squirrel@webmail.ebi.ac.uk> Hi, Just to make the point that of course ensembl compara does not cover the breadth of species we'd wish it to and so GOA does still create manual ISS as described in our GO_REF:0000024 Evelyn > Yes it would be nice to have an evaluation on a per MOD basis.. > > Evelyn > > >> Ah I see....probably lots of things have changed since the paper was >> reviewed.... >> >> A lot of my community use the ISS annotations to direct their >> experiments, so I *hope* they don't have a 28-30% error rate ;) I would >> get blasted ! >> >> Val >> >> >> camon at ebi.ac.uk wrote: >> >>>Hi Val, >>> >>>GO seq lite I believe has no IEA annotations ??? therefore lighter:-)) >>> >>>This paper was reviewed along time ago before very detailed discussions >>> on >>>improving ISS annotations. Admitedly I now realise that I only commented >>>on how GOA was creating ISS annotations at the time(probably wrongly >>>thought he was just considering the human go annotations) and we indeed >>>did use blast hits, protein and gene names etc.. to create ISS >>>assumptions(not considering synteny etc..). This was of course not ideal >>>which is why we are now using ensembl compara(which is better than the >>> way >>>we manually did ISS). I think at least for human GO annotations where >>>there is a huge number of publications out there for us to curate, at >>>least our time is better spent on manual experimental coded annotations. >>> >>>cheers, >>> >>>Evelyn >>> >>> >>> >>>>I only skim read the paper but my main concern was that they are >>>> making >>>>the assumption that GO curated ISS annotations are derived from top >>>>Blast hits? >>>>Although a more minor point would be that they don't reilise there are >>>>procedures in place to prevent transitive annotations (but these are >>>>newer). >>>> >>>>They are pointing out correctly,that it is frequently inaccurate to >>>>make an ISS from Blast (even from a Blast hit to a characterised gene), >>>>but their assumption appears to be that this is how GO curators make >>>> ISS >>>>annotations. I don't think any consortium member (or Uniprot) have ever >>>>made annotations directly from Blast have they? >>>> >>>>Most require robust ortholog predictions (followed up with more >>>> analysis >>>>if ambiguous), or detailed evaluation of protein family membership >>>> using >>>>domain organisation etc. ISS annotations also need to be evaluated in >>>>the context of protein copy number and species distribution, and more >>>>conservative (general) annotations made where appropriate. >>>>Alternatively, if an ISS comes from a paper, these are usually >>>>accompanied by a multiple alignment made with knowledge of the author >>>> of >>>>the ortholog/family members/ biological roles, so these are usually >>>> also >>>>not susceptible to the same errors as a pairwise Blast hit. >>>> >>>>I can't work out how they can estimate an error rate with the methods >>>>they used, because they don't appear to be aware of how the curated ISS >>>>annotations are made in the first place? >>>> >>>>Although maybe this is because I don't know what GOSeqLite is? >>>>I couldn't find anything when I searched the GO website for this and >>>> the >>>>only refs to it when I Google are this paper..... >>>> >>>>Val >>>> >>>> >>>> >>>> >>>> >>>>Jennifer Deegan (nee Clark) wrote: >>>> >>>> >>>> >>>>>That seems an awful lot like publishing a paper to point out that dogs >>>>>have four legs. Shouldn't people know that making an ISS from an ISS >>>>>is daft? It sounds to me ad if he is ranting about people outside the >>>>>consortium doing this rather than us doing it. >>>>> >>>>>Jen >>>>> >>>>>Valerie Wood wrote: >>>>> >>>>> >>>>> >>>>>>Seen this? >>>>>> >>>>>>The authors make a large number of incorrect assumptions about how >>>>>>curated ISS annotations are made......and estimate an error rate of >>>>>>28-30% >>>>>> >>>>>> >>>>>>Jones C., A. Brown & U. Baumann (2007): Estimating the annotation >>>>>>error rate >>>>>>of curated GO database sequence annotations. BMC Bioinformatics 8, >>>>>>170-. >>>>>> >>>>>>http://www.biomedcentral.com/1471-2105/8/170 >>>>>> >>>>>> >>>>>> >>>>>> >>>> >>>>-- >>>>The Wellcome Trust Sanger Institute is operated by Genome Research >>>>Limited, a charity registered in England with number 1021457 and a >>>>company registered in England with number 2742969, whose registered >>>>office is 215 Euston Road, London, NW1 2BE. >>>> >>>> >>>> >>> >>> >>> >>> >>> >> >> >> >> -- >> The Wellcome Trust Sanger Institute is operated by Genome Research >> Limited, a charity registered in England with number 1021457 and a >> company registered in England with number 2742969, whose registered >> office is 215 Euston Road, London, NW1 2BE. >> > > > From cherry at stanford.edu Mon Jun 18 21:54:19 2007 From: cherry at stanford.edu (Mike Cherry) Date: Mon, 18 Jun 2007 21:54:19 -0700 Subject: [go] everything except wiki is now up Message-ID: <4B5B5DBD-D67C-4EA9-9D71-A7E4D6800A44@stanford.edu> Hi, We have restored most of the GO services. Everything should be up except the wikis. Hopefully we'll get them recovered tomorrow. The massive power outage on campus was long enough that our 40KW UPS batteries ran dry. Everything seemed to work and all the machines and databases shut down one all machines but one. Then to add to that the system disk on a major server went bad. Thats the server that provides the wikis. -Mike From hjd at informatics.jax.org Tue Jun 19 05:39:35 2007 From: hjd at informatics.jax.org (Harold Drabkin) Date: Tue, 19 Jun 2007 08:39:35 -0400 Subject: [go] GO:0018444 namespace Message-ID: <4677CE87.9060301@informatics.jax.org> Our load server found GO:0018444 to not have a namespace. I fixed this as of 8:37 AM EST, so it should be public in the normal amount of time. hjd From midori at ebi.ac.uk Tue Jun 19 07:46:15 2007 From: midori at ebi.ac.uk (Midori Harris) Date: Tue, 19 Jun 2007 15:46:15 +0100 (BST) Subject: [go] Alert: Proposal to obsolete two process ontology terms that impacts existing annotation Message-ID: The proposal has been made to obsolete enhancement of virulence ; GO:0046800 reduction of virulence ; GO:0046803 There exist today annotations to these terms as follows: enhancement of virulence ; GO:0046800 GOA_human 2 GOA_uniprot 19 all IEA tigr_Dethenogenes 1 reduction of virulence ; GO:0046803 GOA_human 2 This terms are not used in external mappings, and are not part of any GO slim set maintained within the OBO flat file. The reason for this proposal is that 'virulence' is not a biological process; however, alteration of virulence also does not fit under 'regulation of biological quality' because it is a product both of the genotype/phenotype of the infecting organism and the genotype/phenotype of the organism being infected and varies by individual within a species both for the infecting organism and the infected organism. Link to SourceForge discussion: https://sourceforge.net/tracker/?func=detail&atid=440764&aid=1582761&group_id=36855 The two-week comment period ends on Tuesday, July 3, 2007. Midori (and Alex) From gail at genome.Stanford.EDU Tue Jun 19 08:24:40 2007 From: gail at genome.Stanford.EDU (Gail Binkley) Date: Tue, 19 Jun 2007 08:24:40 -0700 (PDT) Subject: [go] Everything for GO is now back up and running In-Reply-To: <4B5B5DBD-D67C-4EA9-9D71-A7E4D6800A44@stanford.edu> References: <4B5B5DBD-D67C-4EA9-9D71-A7E4D6800A44@stanford.edu> Message-ID: Hi, After a major power outage in Palo Alto that most likely contributed to a system disk failure, all GO services from Stanford are now operational again, including the GO wiki and GOC wiki. Thank you for your patience and understanding. Don't hesitate to contact go-admin at genome.stanford.edu if you experience any problems. Thanks, Gail Binkley On Mon, 18 Jun 2007, Mike Cherry wrote: > Hi, > > We have restored most of the GO services. Everything should be up except the > wikis. Hopefully we'll get them recovered tomorrow. The massive power > outage on campus was long enough that our 40KW UPS batteries ran dry. > Everything seemed to work and all the machines and databases shut down one > all machines but one. Then to add to that the system disk on a major server > went bad. Thats the server that provides the wikis. > > -Mike From jane at ebi.ac.uk Tue Jun 19 09:02:54 2007 From: jane at ebi.ac.uk (Jane Lomax) Date: Tue, 19 Jun 2007 17:02:54 +0100 (BST) Subject: [go] GO:0018444 namespace In-Reply-To: <4677CE87.9060301@informatics.jax.org> References: <4677CE87.9060301@informatics.jax.org> Message-ID: anyone have any idea what caused this? jane On Tue, 19 Jun 2007, Harold Drabkin wrote: > Our load server found GO:0018444 to not have a namespace. I fixed this as of > 8:37 AM EST, so it should be public in the normal amount of time. > > hjd > Dr Jane Lomax GO Editorial Office EMBL-EBI Wellcome Trust Genome Campus Hinxton Cambridgeshire, UK CB10 1SD p: +44 1223 492516 f: +44 1223 494468 From camon at ebi.ac.uk Thu Jun 21 07:16:06 2007 From: camon at ebi.ac.uk (camon at ebi.ac.uk) Date: Thu, 21 Jun 2007 15:16:06 +0100 (BST) Subject: [go] Double taxon ID annotation restriction Message-ID: <59139.217.43.213.3.1182435366.squirrel@webmail.ebi.ac.uk> ISSUE: ExtraTax column Hi I understand that the an extra taxon ID will only be added to association files with the use of a GO term that is a child of the 'multispecies process' term (http://www.ebi.ac.uk/ego/DisplayGoTerm?id=GO:0051704). I would like to ask why we should have to have this restriction... for example if I was to annotate an immune gene with 'defense response to protozoan' GO:0042832 why should I not also be able to indicate via an extra taxon id which protozoan was experimented on. Surely users might like to retrieve which genes were involved in a immune response to say Eimeria? Just raising it now as there is the possibility that some GOC members might be focussing on immune gene GO annotation (if WT grant successful) cheers, Evelyn From jane at ebi.ac.uk Thu Jun 21 07:21:37 2007 From: jane at ebi.ac.uk (Jane Lomax) Date: Thu, 21 Jun 2007 15:21:37 +0100 (BST) Subject: [go] Double taxon ID annotation restriction In-Reply-To: <59139.217.43.213.3.1182435366.squirrel@webmail.ebi.ac.uk> References: <59139.217.43.213.3.1182435366.squirrel@webmail.ebi.ac.uk> Message-ID: Hi Ev - we should just make 'defense response to other organism' (of which 'defense response to protozoan' GO:0042832 is a child) a child of 'multispecies process'...I'm not sure why is isn't already, think it was an oversight. That would solve the problem... jane On Thu, 21 Jun 2007 camon at ebi.ac.uk wrote: > ISSUE: ExtraTax column > > Hi > > I understand that the an extra taxon ID will only be added to association > files with the use of a GO term that is a child of the 'multispecies > process' term (http://www.ebi.ac.uk/ego/DisplayGoTerm?id=GO:0051704). > > I would like to ask why we should have to have this restriction... > for example if I was to annotate an immune gene with 'defense response to > protozoan' GO:0042832 why should I not also be able to indicate via an > extra taxon id which protozoan was experimented on. Surely users might > like to retrieve which genes were involved in a immune response to say > Eimeria? > > Just raising it now as there is the possibility that some GOC members > might be focussing on immune gene GO annotation (if WT grant successful) > > cheers, > > Evelyn > > Dr Jane Lomax GO Editorial Office EMBL-EBI Wellcome Trust Genome Campus Hinxton Cambridgeshire, UK CB10 1SD p: +44 1223 492516 f: +44 1223 494468 From jane at ebi.ac.uk Thu Jun 21 07:57:53 2007 From: jane at ebi.ac.uk (Jane Lomax) Date: Thu, 21 Jun 2007 15:57:53 +0100 (BST) Subject: [go] Double taxon ID annotation restriction In-Reply-To: <467A8F6B.3000804@tigr.org> References: <59139.217.43.213.3.1182435366.squirrel@webmail.ebi.ac.uk> <467A8F6B.3000804@tigr.org> Message-ID: Urrg - I can't remember what we agreed now (my apologies, I should have changed the documentation as soon as we reached a consensus). I *think* we agreed that dual taxon can *only* be used where the GO term being annotated to is a child of 'multiorganism process', and that dual-taxon is only *required* where the term is a child of 'multi-species process' (this was so mouse etc wouldn't be required to implement dual-taxon for just processes like 'pregnancy' where the taxon info isn't really useful anyway) Is that what you remember Michelle? And Emily? Jane On Thu, 21 Jun 2007, Michelle Gwinn Giglio wrote: > > Hi, > > Is there a term "multispecies process"? I think actually the term we are > restricting use of the dual taxon id to is "multiorganism process". (Just > making sure I'm on the same page, not trying to be nit-picky.) > > Michelle > > > > > > Jane Lomax wrote: >> Hi Ev - we should just make 'defense response to other organism' (of which >> 'defense response to protozoan' GO:0042832 is a child) a child of >> 'multispecies process'...I'm not sure why is isn't already, think it was an >> oversight. >> >> That would solve the problem... >> >> jane >> >> >> >> On Thu, 21 Jun 2007 camon at ebi.ac.uk wrote: >> >>> ISSUE: ExtraTax column >>> >>> Hi >>> >>> I understand that the an extra taxon ID will only be added to association >>> files with the use of a GO term that is a child of the 'multispecies >>> process' term (http://www.ebi.ac.uk/ego/DisplayGoTerm?id=GO:0051704). >>> >>> I would like to ask why we should have to have this restriction... >>> for example if I was to annotate an immune gene with 'defense response to >>> protozoan' GO:0042832 why should I not also be able to indicate via an >>> extra taxon id which protozoan was experimented on. Surely users might >>> like to retrieve which genes were involved in a immune response to say >>> Eimeria? >>> >>> Just raising it now as there is the possibility that some GOC members >>> might be focussing on immune gene GO annotation (if WT grant successful) >>> >>> cheers, >>> >>> Evelyn >>> >>> >> >> Dr Jane Lomax >> GO Editorial Office >> EMBL-EBI >> Wellcome Trust Genome Campus >> Hinxton >> Cambridgeshire, UK >> CB10 1SD >> >> p: +44 1223 492516 >> f: +44 1223 494468 > Dr Jane Lomax GO Editorial Office EMBL-EBI Wellcome Trust Genome Campus Hinxton Cambridgeshire, UK CB10 1SD p: +44 1223 492516 f: +44 1223 494468 From jane at ebi.ac.uk Thu Jun 21 08:13:25 2007 From: jane at ebi.ac.uk (Jane Lomax) Date: Thu, 21 Jun 2007 16:13:25 +0100 (BST) Subject: [go] Double taxon ID annotation restriction In-Reply-To: <467A93C0.9010201@tigr.org> References: <59139.217.43.213.3.1182435366.squirrel@webmail.ebi.ac.uk> <467A8F6B.3000804@tigr.org> <467A93C0.9010201@tigr.org> Message-ID: Hi Michelle - it's always reassuring when you find you still agree with yourself isn't it? ;) That term is actually called 'interspecies interaction between organisms'...and yes, it's coming back to me now - I agree too - we shouldn't ever require dual taxa, and that means the documentation is correct as it stands - phew! jane On Thu, 21 Jun 2007, Michelle Gwinn Giglio wrote: > > > Hi, > > I can't even find the term "multi-species process" in AmiGO. > > I seem to recall that we agreed that anything under "mutiorganism process" > *could* have a dual taxon annotation but was NOT required to. > > As for times when the dual taxon annotation was *required* - I don't actually > remember saying that there was any time that it was required. I found the > old email and here is what I said (and luckily I still agree with myself): > "I'm not sure it will always be possible to enter a taxon_id, especially if > one is annotating based on sequence similarity - none might not know exactly > which species an interaction is occuring with but just that one is likely to > occur. Also, there might be issues if interactions occur with more than one > diverse species (I don't know of any cases, but I can imagine them.)" > > So, I'm not sure we should ever *require* the other taxon be put in. > Emily's response to me indicated agreement with that I think. > > Michelle > > > > > > Jane Lomax wrote: >> >> Urrg - I can't remember what we agreed now (my apologies, I should have >> changed the documentation as soon as we reached a consensus). I *think* we >> agreed that dual taxon can *only* be used where the GO term being annotated >> to is a child of 'multiorganism process', and that dual-taxon is only >> *required* where the term is a child of 'multi-species process' (this was >> so mouse etc wouldn't be required to implement dual-taxon for just >> processes like 'pregnancy' where the taxon info isn't really useful anyway) >> >> Is that what you remember Michelle? And Emily? >> >> Jane >> >> >> On Thu, 21 Jun 2007, Michelle Gwinn Giglio wrote: >> >>> >>> Hi, >>> >>> Is there a term "multispecies process"? I think actually the term we are >>> restricting use of the dual taxon id to is "multiorganism process". (Just >>> making sure I'm on the same page, not trying to be nit-picky.) >>> >>> Michelle >>> >>> >>> >>> >>> >>> Jane Lomax wrote: >>> >>>> Hi Ev - we should just make 'defense response to other organism' (of >>>> which 'defense response to protozoan' GO:0042832 is a child) a child of >>>> 'multispecies process'...I'm not sure why is isn't already, think it was >>>> an oversight. >>>> >>>> That would solve the problem... >>>> >>>> jane >>>> >>>> >>>> >>>> On Thu, 21 Jun 2007 camon at ebi.ac.uk wrote: >>>> >>>>> ISSUE: ExtraTax column >>>>> >>>>> Hi >>>>> >>>>> I understand that the an extra taxon ID will only be added to >>>>> association >>>>> files with the use of a GO term that is a child of the 'multispecies >>>>> process' term (http://www.ebi.ac.uk/ego/DisplayGoTerm?id=GO:0051704). >>>>> >>>>> I would like to ask why we should have to have this restriction... >>>>> for example if I was to annotate an immune gene with 'defense response >>>>> to >>>>> protozoan' GO:0042832 why should I not also be able to indicate via an >>>>> extra taxon id which protozoan was experimented on. Surely users might >>>>> like to retrieve which genes were involved in a immune response to say >>>>> Eimeria? >>>>> >>>>> Just raising it now as there is the possibility that some GOC members >>>>> might be focussing on immune gene GO annotation (if WT grant successful) >>>>> >>>>> cheers, >>>>> >>>>> Evelyn >>>>> >>>>> >>>> >>>> Dr Jane Lomax >>>> GO Editorial Office >>>> EMBL-EBI >>>> Wellcome Trust Genome Campus >>>> Hinxton >>>> Cambridgeshire, UK >>>> CB10 1SD >>>> >>>> p: +44 1223 492516 >>>> f: +44 1223 494468 >>> >>> >> >> Dr Jane Lomax >> GO Editorial Office >> EMBL-EBI >> Wellcome Trust Genome Campus >> Hinxton >> Cambridgeshire, UK >> CB10 1SD >> >> p: +44 1223 492516 >> f: +44 1223 494468 > Dr Jane Lomax GO Editorial Office EMBL-EBI Wellcome Trust Genome Campus Hinxton Cambridgeshire, UK CB10 1SD p: +44 1223 492516 f: +44 1223 494468 From jdeegan at ebi.ac.uk Thu Jun 21 08:27:05 2007 From: jdeegan at ebi.ac.uk (Jennifer Deegan (nee Clark)) Date: Thu, 21 Jun 2007 16:27:05 +0100 Subject: [go] Double taxon ID annotation restriction In-Reply-To: References: <59139.217.43.213.3.1182435366.squirrel@webmail.ebi.ac.uk> <467A8F6B.3000804@tigr.org> <467A93C0.9010201@tigr.org> Message-ID: <467A98C9.3070104@ebi.ac.uk> Hi Jane, Emily told us the other day that this was only for descendents of multi-organism process and that it was never required. Jen Jane Lomax wrote: > Hi Michelle - it's always reassuring when you find you still agree > with yourself isn't it? ;) > > That term is actually called 'interspecies interaction between > organisms'...and yes, it's coming back to me now - I agree too - we > shouldn't ever require dual taxa, and that means the documentation is > correct as it stands - phew! > > jane > > On Thu, 21 Jun 2007, Michelle Gwinn Giglio wrote: > >> >> >> Hi, >> >> I can't even find the term "multi-species process" in AmiGO. >> >> I seem to recall that we agreed that anything under "mutiorganism >> process" *could* have a dual taxon annotation but was NOT required to. >> >> As for times when the dual taxon annotation was *required* - I don't >> actually remember saying that there was any time that it was >> required. I found the old email and here is what I said (and luckily >> I still agree with myself): >> "I'm not sure it will always be possible to enter a taxon_id, >> especially if one is annotating based on sequence similarity - none >> might not know exactly which species an interaction is occuring with >> but just that one is likely to occur. Also, there might be issues if >> interactions occur with more than one diverse species (I don't know >> of any cases, but I can imagine them.)" >> >> So, I'm not sure we should ever *require* the other taxon be put in. >> Emily's response to me indicated agreement with that I think. >> >> Michelle >> >> >> >> >> >> Jane Lomax wrote: >> >>> >>> Urrg - I can't remember what we agreed now (my apologies, I should >>> have changed the documentation as soon as we reached a consensus). I >>> *think* we >>> agreed that dual taxon can *only* be used where the GO term being >>> annotated to is a child of 'multiorganism process', and that >>> dual-taxon is only *required* where the term is a child of >>> 'multi-species process' (this was so mouse etc wouldn't be required >>> to implement dual-taxon for just >>> processes like 'pregnancy' where the taxon info isn't really useful >>> anyway) >>> >>> Is that what you remember Michelle? And Emily? >>> >>> Jane >>> >>> >>> On Thu, 21 Jun 2007, Michelle Gwinn Giglio wrote: >>> >>>> >>>> Hi, >>>> >>>> Is there a term "multispecies process"? I think actually the term >>>> we are restricting use of the dual taxon id to is "multiorganism >>>> process". (Just making sure I'm on the same page, not trying to be >>>> nit-picky.) >>>> >>>> Michelle >>>> >>>> >>>> >>>> >>>> >>>> Jane Lomax wrote: >>>> >>>>> Hi Ev - we should just make 'defense response to other organism' >>>>> (of which 'defense response to protozoan' GO:0042832 is a child) a >>>>> child of 'multispecies process'...I'm not sure why is isn't >>>>> already, think it was an oversight. >>>>> >>>>> That would solve the problem... >>>>> >>>>> jane >>>>> >>>>> >>>>> >>>>> On Thu, 21 Jun 2007 camon at ebi.ac.uk wrote: >>>>> >>>>>> ISSUE: ExtraTax column >>>>>> >>>>>> Hi >>>>>> >>>>>> I understand that the an extra taxon ID will only be added to >>>>>> association >>>>>> files with the use of a GO term that is a child of the 'multispecies >>>>>> process' term >>>>>> (http://www.ebi.ac.uk/ego/DisplayGoTerm?id=GO:0051704). >>>>>> >>>>>> I would like to ask why we should have to have this restriction... >>>>>> for example if I was to annotate an immune gene with 'defense >>>>>> response to >>>>>> protozoan' GO:0042832 why should I not also be able to indicate >>>>>> via an >>>>>> extra taxon id which protozoan was experimented on. Surely users >>>>>> might >>>>>> like to retrieve which genes were involved in a immune response >>>>>> to say >>>>>> Eimeria? >>>>>> >>>>>> Just raising it now as there is the possibility that some GOC >>>>>> members >>>>>> might be focussing on immune gene GO annotation (if WT grant >>>>>> successful) >>>>>> >>>>>> cheers, >>>>>> >>>>>> Evelyn >>>>>> >>>>>> >>>>> >>>>> Dr Jane Lomax >>>>> GO Editorial Office >>>>> EMBL-EBI >>>>> Wellcome Trust Genome Campus >>>>> Hinxton >>>>> Cambridgeshire, UK >>>>> CB10 1SD >>>>> >>>>> p: +44 1223 492516 >>>>> f: +44 1223 494468 >>>> >>>> >>>> >>> >>> Dr Jane Lomax >>> GO Editorial Office >>> EMBL-EBI >>> Wellcome Trust Genome Campus >>> Hinxton >>> Cambridgeshire, UK >>> CB10 1SD >>> >>> p: +44 1223 492516 >>> f: +44 1223 494468 >> >> > > Dr Jane Lomax > GO Editorial Office > EMBL-EBI > Wellcome Trust Genome Campus > Hinxton > Cambridgeshire, UK > CB10 1SD > > p: +44 1223 492516 > f: +44 1223 494468 -- Jennifer Deegan nee Clark EMBL-European Bioinformatics Institute Gene Ontology Consortium From midori at ebi.ac.uk Thu Jun 21 08:52:03 2007 From: midori at ebi.ac.uk (Midori Harris) Date: Thu, 21 Jun 2007 16:52:03 +0100 (BST) Subject: [go] June 20 managers call - minutes available Message-ID: Hi, The minutes from yesterday's GO Managers conference call are now on the internal wiki: http://gocwiki.geneontology.org/index.php/Managers_20Jun07 If you would like a particular issue to be discussed at the next managers' call, please contact the relevant manager(s): Reference Genomes: Rex User Advocacy: Jane and Eurie Content Development: Midori and David Annotation Outreach: Jennifer Software: Chris For general management and budget issues, contact the GO PIs . Midori From edimmer at ebi.ac.uk Thu Jun 21 09:11:25 2007 From: edimmer at ebi.ac.uk (E Dimmer) Date: Thu, 21 Jun 2007 17:11:25 +0100 Subject: [go] Double taxon ID annotation restriction In-Reply-To: <467A98C9.3070104@ebi.ac.uk> References: <59139.217.43.213.3.1182435366.squirrel@webmail.ebi.ac.uk> <467A8F6B.3000804@tigr.org> <467A93C0.9010201@tigr.org> <467A98C9.3070104@ebi.ac.uk> Message-ID: <467AA32D.2090908@ebi.ac.uk> Hi, Yes, thats how I remember (and have implemented the sanity check now in protein2go) - only for descendents of multi-organism process node - and even then desirable to add the second taxon id when possible, but not essential. Cheers, Emily Jennifer Deegan (nee Clark) wrote: > Hi Jane, > > Emily told us the other day that this was only for descendents of > multi-organism process and that it was never required. > > Jen > > Jane Lomax wrote: > >> Hi Michelle - it's always reassuring when you find you still agree >> with yourself isn't it? ;) >> >> That term is actually called 'interspecies interaction between >> organisms'...and yes, it's coming back to me now - I agree too - we >> shouldn't ever require dual taxa, and that means the documentation is >> correct as it stands - phew! >> >> jane >> >> On Thu, 21 Jun 2007, Michelle Gwinn Giglio wrote: >> >>> >>> >>> Hi, >>> >>> I can't even find the term "multi-species process" in AmiGO. >>> >>> I seem to recall that we agreed that anything under "mutiorganism >>> process" *could* have a dual taxon annotation but was NOT required to. >>> >>> As for times when the dual taxon annotation was *required* - I don't >>> actually remember saying that there was any time that it was >>> required. I found the old email and here is what I said (and >>> luckily I still agree with myself): >>> "I'm not sure it will always be possible to enter a taxon_id, >>> especially if one is annotating based on sequence similarity - none >>> might not know exactly which species an interaction is occuring with >>> but just that one is likely to occur. Also, there might be issues >>> if interactions occur with more than one diverse species (I don't >>> know of any cases, but I can imagine them.)" >>> >>> So, I'm not sure we should ever *require* the other taxon be put in. >>> Emily's response to me indicated agreement with that I think. >>> >>> Michelle >>> >>> >>> >>> >>> >>> Jane Lomax wrote: >>> >>>> >>>> Urrg - I can't remember what we agreed now (my apologies, I should >>>> have changed the documentation as soon as we reached a consensus). >>>> I *think* we >>>> agreed that dual taxon can *only* be used where the GO term being >>>> annotated to is a child of 'multiorganism process', and that >>>> dual-taxon is only *required* where the term is a child of >>>> 'multi-species process' (this was so mouse etc wouldn't be required >>>> to implement dual-taxon for just >>>> processes like 'pregnancy' where the taxon info isn't really useful >>>> anyway) >>>> >>>> Is that what you remember Michelle? And Emily? >>>> >>>> Jane >>>> >>>> >>>> On Thu, 21 Jun 2007, Michelle Gwinn Giglio wrote: >>>> >>>>> >>>>> Hi, >>>>> >>>>> Is there a term "multispecies process"? I think actually the term >>>>> we are restricting use of the dual taxon id to is "multiorganism >>>>> process". (Just making sure I'm on the same page, not trying to >>>>> be nit-picky.) >>>>> >>>>> Michelle >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Jane Lomax wrote: >>>>> >>>>>> Hi Ev - we should just make 'defense response to other organism' >>>>>> (of which 'defense response to protozoan' GO:0042832 is a child) >>>>>> a child of 'multispecies process'...I'm not sure why is isn't >>>>>> already, think it was an oversight. >>>>>> >>>>>> That would solve the problem... >>>>>> >>>>>> jane >>>>>> >>>>>> >>>>>> >>>>>> On Thu, 21 Jun 2007 camon at ebi.ac.uk wrote: >>>>>> >>>>>>> ISSUE: ExtraTax column >>>>>>> >>>>>>> Hi >>>>>>> >>>>>>> I understand that the an extra taxon ID will only be added to >>>>>>> association >>>>>>> files with the use of a GO term that is a child of the >>>>>>> 'multispecies >>>>>>> process' term >>>>>>> (http://www.ebi.ac.uk/ego/DisplayGoTerm?id=GO:0051704). >>>>>>> >>>>>>> I would like to ask why we should have to have this restriction... >>>>>>> for example if I was to annotate an immune gene with 'defense >>>>>>> response to >>>>>>> protozoan' GO:0042832 why should I not also be able to indicate >>>>>>> via an >>>>>>> extra taxon id which protozoan was experimented on. Surely >>>>>>> users might >>>>>>> like to retrieve which genes were involved in a immune response >>>>>>> to say >>>>>>> Eimeria? >>>>>>> >>>>>>> Just raising it now as there is the possibility that some GOC >>>>>>> members >>>>>>> might be focussing on immune gene GO annotation (if WT grant >>>>>>> successful) >>>>>>> >>>>>>> cheers, >>>>>>> >>>>>>> Evelyn >>>>>>> >>>>>>> >>>>>> >>>>>> Dr Jane Lomax >>>>>> GO Editorial Office >>>>>> EMBL-EBI >>>>>> Wellcome Trust Genome Campus >>>>>> Hinxton >>>>>> Cambridgeshire, UK >>>>>> CB10 1SD >>>>>> >>>>>> p: +44 1223 492516 >>>>>> f: +44 1223 494468 >>>>> >>>>> >>>>> >>>> >>>> Dr Jane Lomax >>>> GO Editorial Office >>>> EMBL-EBI >>>> Wellcome Trust Genome Campus >>>> Hinxton >>>> Cambridgeshire, UK >>>> CB10 1SD >>>> >>>> p: +44 1223 492516 >>>> f: +44 1223 494468 >>> >>> >> >> Dr Jane Lomax >> GO Editorial Office >> EMBL-EBI >> Wellcome Trust Genome Campus >> Hinxton >> Cambridgeshire, UK >> CB10 1SD >> >> p: +44 1223 492516 >> f: +44 1223 494468 > > > -- ************************************ Emily Dimmer GOA Coordinator EMBL-EBI Wellcome Trust Genome Campus Hinxton Cambridge CB10 1SD, U.K. Tel: +44 1223 494654 Fax: +44 1223 494468 email: edimmer at ebi.ac.uk ************************************ From rama at genome.Stanford.EDU Thu Jun 21 15:18:36 2007 From: rama at genome.Stanford.EDU (Rama Balakrishnan) Date: Thu, 21 Jun 2007 15:18:36 -0700 Subject: [go] Double taxon ID annotation restriction In-Reply-To: <467AA32D.2090908@ebi.ac.uk> References: <59139.217.43.213.3.1182435366.squirrel@webmail.ebi.ac.uk> <467A8F6B.3000804@tigr.org> <467A93C0.9010201@tigr.org> <467A98C9.3070104@ebi.ac.uk> <467AA32D.2090908@ebi.ac.uk> Message-ID: <59F4CB0C-94E8-4085-90D9-9924ED772EBD@genome.stanford.edu> Well, until now I did not know that the TaxonID column can take IDs for multiple species. Aren't we overloading this column and confusing users? BTW, I am not sure how we display such annotations in AmiGO. rama On Jun 21, 2007, at 9:11 AM, E Dimmer wrote: > Hi, > Yes, thats how I remember (and have implemented the sanity check > now in protein2go) > > - only for descendents of multi-organism process node > - and even then desirable to add the second taxon id when possible, > but not essential. > > Cheers, > Emily > > > Jennifer Deegan (nee Clark) wrote: >> Hi Jane, >> >> Emily told us the other day that this was only for descendents of >> multi-organism process and that it was never required. >> >> Jen >> >> Jane Lomax wrote: >> >>> Hi Michelle - it's always reassuring when you find you still >>> agree with yourself isn't it? ;) >>> >>> That term is actually called 'interspecies interaction between >>> organisms'...and yes, it's coming back to me now - I agree too - >>> we shouldn't ever require dual taxa, and that means the >>> documentation is >>> correct as it stands - phew! >>> >>> jane >>> >>> On Thu, 21 Jun 2007, Michelle Gwinn Giglio wrote: >>> >>>> >>>> >>>> Hi, >>>> >>>> I can't even find the term "multi-species process" in AmiGO. >>>> >>>> I seem to recall that we agreed that anything under >>>> "mutiorganism process" *could* have a dual taxon annotation but >>>> was NOT required to. >>>> >>>> As for times when the dual taxon annotation was *required* - I >>>> don't actually remember saying that there was any time that it >>>> was required. I found the old email and here is what I said >>>> (and luckily I still agree with myself): >>>> "I'm not sure it will always be possible to enter a taxon_id, >>>> especially if one is annotating based on sequence similarity - >>>> none might not know exactly which species an interaction is >>>> occuring with but just that one is likely to occur. Also, there >>>> might be issues if interactions occur with more than one diverse >>>> species (I don't know of any cases, but I can imagine them.)" >>>> >>>> So, I'm not sure we should ever *require* the other taxon be put >>>> in. >>>> Emily's response to me indicated agreement with that I think. >>>> >>>> Michelle >>>> >>>> >>>> >>>> >>>> >>>> Jane Lomax wrote: >>>> >>>>> >>>>> Urrg - I can't remember what we agreed now (my apologies, I >>>>> should have changed the documentation as soon as we reached a >>>>> consensus). I *think* we >>>>> agreed that dual taxon can *only* be used where the GO term >>>>> being annotated to is a child of 'multiorganism process', and >>>>> that dual-taxon is only *required* where the term is a child of >>>>> 'multi-species process' (this was so mouse etc wouldn't be >>>>> required to implement dual-taxon for just >>>>> processes like 'pregnancy' where the taxon info isn't really >>>>> useful anyway) >>>>> >>>>> Is that what you remember Michelle? And Emily? >>>>> >>>>> Jane >>>>> >>>>> >>>>> On Thu, 21 Jun 2007, Michelle Gwinn Giglio wrote: >>>>> >>>>>> >>>>>> Hi, >>>>>> >>>>>> Is there a term "multispecies process"? I think actually the >>>>>> term we are restricting use of the dual taxon id to is >>>>>> "multiorganism process". (Just making sure I'm on the same >>>>>> page, not trying to be nit-picky.) >>>>>> >>>>>> Michelle >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Jane Lomax wrote: >>>>>> >>>>>>> Hi Ev - we should just make 'defense response to other >>>>>>> organism' (of which 'defense response to protozoan' GO: >>>>>>> 0042832 is a child) a child of 'multispecies process'...I'm >>>>>>> not sure why is isn't already, think it was an oversight. >>>>>>> >>>>>>> That would solve the problem... >>>>>>> >>>>>>> jane >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, 21 Jun 2007 camon at ebi.ac.uk wrote: >>>>>>> >>>>>>>> ISSUE: ExtraTax column >>>>>>>> >>>>>>>> Hi >>>>>>>> >>>>>>>> I understand that the an extra taxon ID will only be added >>>>>>>> to association >>>>>>>> files with the use of a GO term that is a child of the >>>>>>>> 'multispecies >>>>>>>> process' term (http://www.ebi.ac.uk/ego/DisplayGoTerm?id=GO: >>>>>>>> 0051704). >>>>>>>> >>>>>>>> I would like to ask why we should have to have this >>>>>>>> restriction... >>>>>>>> for example if I was to annotate an immune gene with >>>>>>>> 'defense response to >>>>>>>> protozoan' GO:0042832 why should I not also be able to >>>>>>>> indicate via an >>>>>>>> extra taxon id which protozoan was experimented on. Surely >>>>>>>> users might >>>>>>>> like to retrieve which genes were involved in a immune >>>>>>>> response to say >>>>>>>> Eimeria? >>>>>>>> >>>>>>>> Just raising it now as there is the possibility that some >>>>>>>> GOC members >>>>>>>> might be focussing on immune gene GO annotation (if WT grant >>>>>>>> successful) >>>>>>>> >>>>>>>> cheers, >>>>>>>> >>>>>>>> Evelyn >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> Dr Jane Lomax >>>>>>> GO Editorial Office >>>>>>> EMBL-EBI >>>>>>> Wellcome Trust Genome Campus >>>>>>> Hinxton >>>>>>> Cambridgeshire, UK >>>>>>> CB10 1SD >>>>>>> >>>>>>> p: +44 1223 492516 >>>>>>> f: +44 1223 494468 >>>>>> >>>>>> >>>>>> >>>>> >>>>> Dr Jane Lomax >>>>> GO Editorial Office >>>>> EMBL-EBI >>>>> Wellcome Trust Genome Campus >>>>> Hinxton >>>>> Cambridgeshire, UK >>>>> CB10 1SD >>>>> >>>>> p: +44 1223 492516 >>>>> f: +44 1223 494468 >>>> >>>> >>> >>> Dr Jane Lomax >>> GO Editorial Office >>> EMBL-EBI >>> Wellcome Trust Genome Campus >>> Hinxton >>> Cambridgeshire, UK >>> CB10 1SD >>> >>> p: +44 1223 492516 >>> f: +44 1223 494468 >> >> >> > > > -- > ************************************ > Emily Dimmer > GOA Coordinator > EMBL-EBI > Wellcome Trust Genome Campus > Hinxton > Cambridge CB10 1SD, U.K. > Tel: +44 1223 494654 > Fax: +44 1223 494468 > email: edimmer at ebi.ac.uk > ************************************ From trudy at vbi.vt.edu Thu Jun 21 17:01:39 2007 From: trudy at vbi.vt.edu (Trudy Torto-Alalibo) Date: Thu, 21 Jun 2007 20:01:39 -0400 (EDT) Subject: [go] Double taxon ID annotation restriction In-Reply-To: <59F4CB0C-94E8-4085-90D9-9924ED772EBD@genome.stanford.edu> References: <59139.217.43.213.3.1182435366.squirrel@webmail.ebi.ac.uk> <467A8F6B.3000804@tigr.org> <467A93C0.9010201@tigr.org> <467A98C9.3070104@ebi.ac.uk> <467AA32D.2090908@ebi.ac.uk> <59F4CB0C-94E8-4085-90D9-9924ED772EBD@genome.stanford.edu> Message-ID: <56373.204.111.138.75.1182470499.squirrel@webmail.vbi.vt.edu> Hi Rama, The PAMGO folks are using this feature a lot. We have not submitted any annotations yet but majority of the annotations we will be submitting will have the "species|species" in the taxon field. Trudy On Thu, June 21, 2007 6:18 pm, Rama Balakrishnan wrote: > Well, until now I did not know that the TaxonID column can take IDs > for multiple species. Aren't we overloading this column and confusing > users? > > BTW, I am not sure how we display such annotations in AmiGO. > > > rama > > > On Jun 21, 2007, at 9:11 AM, E Dimmer wrote: > > >> Hi, >> Yes, thats how I remember (and have implemented the sanity check >> now in protein2go) >> >> - only for descendents of multi-organism process node >> - and even then desirable to add the second taxon id when possible, >> but not essential. >> >> Cheers, >> Emily >> >> >> >> Jennifer Deegan (nee Clark) wrote: >> >>> Hi Jane, >>> >>> >>> Emily told us the other day that this was only for descendents of >>> multi-organism process and that it was never required. >>> >>> Jen >>> >>> >>> Jane Lomax wrote: >>> >>> >>>> Hi Michelle - it's always reassuring when you find you still >>>> agree with yourself isn't it? ;) >>>> >>>> That term is actually called 'interspecies interaction between >>>> organisms'...and yes, it's coming back to me now - I agree too - we >>>> shouldn't ever require dual taxa, and that means the documentation >>>> is correct as it stands - phew! >>>> >>>> jane >>>> >>>> On Thu, 21 Jun 2007, Michelle Gwinn Giglio wrote: >>>> >>>> >>>>> >>>>> >>>>> Hi, >>>>> >>>>> >>>>> I can't even find the term "multi-species process" in AmiGO. >>>>> >>>>> >>>>> I seem to recall that we agreed that anything under >>>>> "mutiorganism process" *could* have a dual taxon annotation but >>>>> was NOT required to. >>>>> >>>>> As for times when the dual taxon annotation was *required* - I >>>>> don't actually remember saying that there was any time that it was >>>>> required. I found the old email and here is what I said (and >>>>> luckily I still agree with myself): "I'm not sure it will always >>>>> be possible to enter a taxon_id, especially if one is annotating >>>>> based on sequence similarity - none might not know exactly which >>>>> species an interaction is occuring with but just that one is >>>>> likely to occur. Also, there might be issues if interactions >>>>> occur with more than one diverse species (I don't know of any >>>>> cases, but I can imagine them.)" >>>>> >>>>> So, I'm not sure we should ever *require* the other taxon be put >>>>> in. Emily's response to me indicated agreement with that I think. >>>>> >>>>> >>>>> Michelle >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Jane Lomax wrote: >>>>> >>>>> >>>>>> >>>>>> Urrg - I can't remember what we agreed now (my apologies, I >>>>>> should have changed the documentation as soon as we reached a >>>>>> consensus). I *think* we agreed that dual taxon can *only* be >>>>>> used where the GO term being annotated to is a child of >>>>>> 'multiorganism process', and >>>>>> that dual-taxon is only *required* where the term is a child of >>>>>> 'multi-species process' (this was so mouse etc wouldn't be >>>>>> required to implement dual-taxon for just processes like >>>>>> 'pregnancy' where the taxon info isn't really >>>>>> useful anyway) >>>>>> >>>>>> Is that what you remember Michelle? And Emily? >>>>>> >>>>>> >>>>>> Jane >>>>>> >>>>>> >>>>>> >>>>>> On Thu, 21 Jun 2007, Michelle Gwinn Giglio wrote: >>>>>> >>>>>> >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> >>>>>>> Is there a term "multispecies process"? I think actually the >>>>>>> term we are restricting use of the dual taxon id to is >>>>>>> "multiorganism process". (Just making sure I'm on the same >>>>>>> page, not trying to be nit-picky.) >>>>>>> >>>>>>> Michelle >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Jane Lomax wrote: >>>>>>> >>>>>>> >>>>>>>> Hi Ev - we should just make 'defense response to other >>>>>>>> organism' (of which 'defense response to protozoan' GO: >>>>>>>> 0042832 is a child) a child of 'multispecies process'...I'm >>>>>>>> not sure why is isn't already, think it was an oversight. >>>>>>>> >>>>>>>> That would solve the problem... >>>>>>>> >>>>>>>> >>>>>>>> jane >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Thu, 21 Jun 2007 camon at ebi.ac.uk wrote: >>>>>>>> >>>>>>>> >>>>>>>>> ISSUE: ExtraTax column >>>>>>>>> >>>>>>>>> >>>>>>>>> Hi >>>>>>>>> >>>>>>>>> >>>>>>>>> I understand that the an extra taxon ID will only be >>>>>>>>> added to association files with the use of a GO term that >>>>>>>>> is a child of the 'multispecies >>>>>>>>> process' term >>>>>>>>> (http://www.ebi.ac.uk/ego/DisplayGoTerm?id=GO: >>>>>>>>> 0051704). >>>>>>>>> >>>>>>>>> >>>>>>>>> I would like to ask why we should have to have this >>>>>>>>> restriction... for example if I was to annotate an immune >>>>>>>>> gene with 'defense response to >>>>>>>>> protozoan' GO:0042832 why should I not also be able to >>>>>>>>> indicate via an extra taxon id which protozoan was >>>>>>>>> experimented on. Surely users might like to retrieve which >>>>>>>>> genes were involved in a immune response to say Eimeria? >>>>>>>>> >>>>>>>>> >>>>>>>>> Just raising it now as there is the possibility that some >>>>>>>>> GOC members >>>>>>>>> might be focussing on immune gene GO annotation (if WT >>>>>>>>> grant successful) >>>>>>>>> >>>>>>>>> cheers, >>>>>>>>> >>>>>>>>> Evelyn >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> Dr Jane Lomax >>>>>>>> GO Editorial Office >>>>>>>> EMBL-EBI >>>>>>>> Wellcome Trust Genome Campus >>