From midori at ebi.ac.uk Tue Sep 1 02:28:36 2009 From: midori at ebi.ac.uk (Midori Harris) Date: Tue, 1 Sep 2009 10:28:36 +0100 (BST) Subject: [Ontology-editors] XP docs In-Reply-To: References:

Message-ID: Chiming in late due to bank holiday yesterday ... I think the doc now looks very good indeed. (Although "classes" would be more ontologically correct, I heartily approve of sticking with "terms" in this documentation, because so much of its target audience is biologists; formal ontologists will mostly look elsewhere anyway.) m On Mon, 31 Aug 2009, Chris Mungall wrote: > > Looks very good! > > Couple of comments: >> If we use ontology terms in the genus and the differentia, we can see >> that these logical definitions take the general form >> >> term relation term >> > The problem is we already use a triple of the form to denote > > all X R some Y > > I suggest that instead of > > term relation term > > You write > > term and relation term > > or > > term that relation term > > e.g. instead of > >> lysosomal membrane is membrane surrounding lysosome >> > > we should have: > > lysosomal membrane is (a) membrane that surrounds (a) lysosome > > This is consistent with what you have above, and with the formal semantics. > Also the actual relation used is 'surrounds' not 'surrounding'. Of course > it's not hard to have a simple algorithm that translates a logical definition > of the form > > lysosomal membrane = membrane that surrounds lysosome > > To a more user-friendly > > a lysosome membrane is a membrane surrounding a lysosome > > But this documentation should not be dependent on such an algorithm. The docs > should probably not shy away from showing the relevant piece of the obo > format stanza and include a translational table for going between the two. > E.g. > > id: X > > intersection_of: G > > intersection_of: R1 Y1 > > intersection_of: Rn Yn > > <=> > > X = G that and ... and > > > > The docs use the terms 'term', 'concept' and 'category'. I'm not sure what > the difference between these are. I think it would be simplest if we use > 'class' throughout. Unfortunately the usage of 'term' for what are actually > classes is very prevalent in GO. We could at least reduce it to term and > class and eliminate concept and category. > > It may be better to use a species-neutral ontology like cell or chebi instead > of the species-specific fly_anatomy. > > For the internal xp examples it would be good to have examples drawn from the > xps that will go live first: the subset of bp_xp_cc that are simple occurs_in Y> ; regulation xps ; the subset of cc_xp_self that is component that part_of X>. We could also have an example of how this is > being used to maintain the GO. > > David and Amina are writing docs for OE users so we should be sure to > coordinate. > > Thanks! > > > > On Aug 28, 2009, at 3:10 PM, Amelia Ireland wrote: > >> Hello people, >> >> I've drafted some XP docs for the GO website if you want to have a look at >> them: >> >> http://geneontology.org/test-html.shtml >> >> If anyone has suggestions for what should go in that last paragraph, they'd >> be gratefully received! >> >> Thanks, >> Amelia. >> >> -- >> Amelia Ireland >> GO Editorial Office >> http://www.berkeleybop.org || http://www.ebi.ac.uk >> Boycott Trader Joe's Red List seafood: http://traitorjoe.com/ >> >> >> >> >> >> >> >> >> _______________________________________________ >> Ontology-editors mailing list >> Ontology-editors at geneontology.org >> http://fafner.stanford.edu/mailman/listinfo/ontology-editors >> > > _______________________________________________ > Ontology-editors mailing list > Ontology-editors at geneontology.org > http://fafner.stanford.edu/mailman/listinfo/ontology-editors From midori at ebi.ac.uk Tue Sep 1 05:40:49 2009 From: midori at ebi.ac.uk (Midori Harris) Date: Tue, 1 Sep 2009 13:40:49 +0100 (BST) Subject: [Ontology-editors] forward and reverse transcription In-Reply-To: References: <64CE8C76-9D79-45F8-9357-4663A9E89D5D@berkeleybop.org> <493411F5.7070109@informatics.jax.org> <49341373.7010000@informatics.jax.org> <49359501.4050000@informatics.jax.org> <4935B884.3010108@informatics.jax.org> <4935C498.5020903@informatics.jax.org> <4935EBE3.90107@informatics.jax.org> <49369C89.70608@informatics.jax.org> <4936A2E0.7000400@informatics.jax.org> <4936A560.10903@informatics.jax.org> <4936AD2B.7030005@informatics.jax.org> <49371535.50401@informatics.jax.org> Message-ID: Hi all, After a few months of dormancy, there have been a few more comments on this SF item. Rather than copy things here, here's the link: https://sourceforge.net/tracker/?func=detail&atid=440764&aid=2354289&group_id=36855# Additional comments welcome. m From kchris at genome.stanford.edu Tue Sep 1 10:24:18 2009 From: kchris at genome.stanford.edu (Karen Christie) Date: Tue, 1 Sep 2009 10:24:18 -0700 (PDT) Subject: [Ontology-editors] [OBO-Edit Working Group] displaying has_part In-Reply-To: References: Message-ID: HI David, I would think of the major spliceosome (and also the minor and trans spliceosomes) as an ordered series of complexes, each composed of some or all of the 5 snRNPs + some other stuff. I don't know that relates to a "non-contiguous structure". Perhaps you could provide an example. -Karen On Tue, 1 Sep 2009, djs93 at gen.cam.ac.uk wrote: > Hi Karen, > > I think there might be another way to deal with this issue, that is to get a > more precise definition of the 'major spliceosome' - one that more closely > accords with what biologists are actually referring too. It seems to me, that > the way you use the term is most consistent with it referring to a > non-contiguous structure - by which I mean one whose parts are not all > connected to each other. As these can be confusing, I think it's important to > use such terms sparingly, but they are unavoidable in some cases. For > example, we need terms for functionally defined systems in anatomy. Instances > of many such systems - e.g.- the immune system or the endocrine system, are > non-contiguous. Is this the case for what you refer to here as the 'major > spliceosome'? If so, then, as far as I can tell, the original use of part_of > in this case was not incorrect. > > Hope this helps, rather than just muddying the waters further, > > David > > On Aug 26 2009, Karen Christie wrote: > >> OK, I understand your explanation about "Why should "Queries for U2-type >> spliceosomal complex should ***not*** return gene products localized >> to U1 snRNP complex." But I think that is separate from the display >> issue I have with has_part. >> >> However, it also brings up a different issue. A question that a >> biologist might want to ask is "give me all the proteins in the major >> spliceosome". They would expect to get the proteins present in the 5 >> snRNPs (U1, U2, U4, U5, and U6). > > >> By replacing part_of relations with >> has_part, it seems that they might have difficulty getting a full >> answer to that question. In your example where g1 is annotated only to >> "U1 snRNP", you give the hypothetical result: >> >>> There are no genes with products known to be localized to 'U2-type >>> spliceosomal complex'. >>> However, every 'U2-type spliceosomal complex' has the following >>> parts: >>> a U1 snRNP -- genes: g1 >>> a U2 snRNP -- genes: none >> >> However, if I wanted to get all proteins in the major spliceosome, I >> don't want just gene products that are in EVERY 'U2-type spliceosomal >> complex', I want gene products that are in ANY 'U2-type spliceosomal >> complex'. What do we need to do to make this a question that biologists >> get a reasonable answer to? >> >> I understand that GO needs to implement more rigorous logic, but if we >> do it in a way that prevents biologists from getting reasonable >> answers, we are not doing what we set out to do. >> >> -Karen >> >> >> >> >> On Mon, 24 Aug 2009, Chris Mungall wrote: >> >>> >>> On Aug 24, 2009, at 10:36 AM, Karen Christie wrote: >>> >>> [snipped part of dialog for now to focus on one issue] >>> >>>>> I would strongly advocate that even given sufficient developer hours it >>>>> is better *not* to display the ontology in this way at all. It perhaps >>>>> looks more comforting, but people will make the same comforting >>>>> assumptions that no longer hold. For example, it looks like there is >>>>> some kind of transitive relationship between U1 snRNP and U2-type >>>>> spliceosomal complex ***which there is not***. It looks like the true >>>>> path rule might hold. ***it does not*** . Queries for U2-type >>>>> spliceosomal complex should ***not*** return gene products localized to >>>>> U1 snRNP complex. >>>> >>>> Why should "Queries for U2-type spliceosomal complex should ***not*** >>>> return gene products localized to U1 snRNP complex."? >>> >>> OK, good, I think we are circling on on the crux of the issue here. >>> >>> According to GO, it is not necessarily the case that a gp localized to a >>> U1 snRNP is necessarily localized to a U2-type spliceosomal complex. For >>> example, the gp may be localized to a particular U1 snRNP that is part of >>> a penta-snRNP complex (I may not have chosen the best example as we're >>> lacking annotations to this new term, but I can pull out an analogous >>> example if you're not convinced) >>> >>> This can be seen in the sub-graph which I reproduce at the end of this >>> email (let me know if this is not visible in some email programs, I can >>> make a wiki page with this all on it) - there is no path following the >>> arrows from U1 snRNP to U2-type spliceosomal complex. Note that attempting >>> to show the graph in an "intuitive" way as I have attempted to do below, >>> with the smaller entities at the bottom, is actually *misleading* because >>> it leads one to assume that there is some inferred all-some relationship >>> between these two terms when in fact there is not. >>> >>> Biology is complex and logic is hard. There's no escaping this. I don't >>> believe we should simplify either to the point where we get false >>> positives. I do think we need better ways of displaying this complex >>> information, but I think we should focus resources on doing this in end >>> user-facing tools rather than oboedit, as we would hope everyone using >>> oboedit to edit the ontology would have an understanding of the logic or a >>> willingness to learn. >>> >>> Here is a roughly sketched out example of how this could work >>> >>> Let's say PMID:123 describes an observation of a product of g1 being >>> localized to a 'U1 snRNP' via an IDA. Let's say that's all we know, either >>> due to the resolution of the assay or that's all that the annotator >>> specified. The user queries for 'U2-type spliceosomal complex' >>> >>> The query result screen could show something like: >>> >>> There are no genes with products known to be localized to 'U2-type >>> spliceosomal complex'. >>> However, every 'U2-type spliceosomal complex' has the following >>> parts: >>> a U1 snRNP -- genes: g1 >>> a U2 snRNP -- genes: none >>> >>> A more advanced tool would be able to show even more: >>> >>> PMID:123 shows g1 in U1 snRNP. >>> prob('U2-type spliceosomal complex') = 0.83 >>> prob('penta-snRNP complex') = 0.05 >>> ... >>> >>> This leads the user to terms of relevance, shows what is known, shows what >>> might be the case, and does not show anything that is false. >>> >>>> I would have >>>> thought that they should. If I wanted to know the parts of "U2-type >>>> spliceosomal complex" I would want to know all the things that compose >>>> the series of complexes that are all considered to be a "U2-type >>>> spliceosomal complex". >>> >>> I'm not sure I really understand the statement, it sounds tautological, I >>> don't understand what adding "series of" adds. >>> >>> If the question is "what parts can be found in every U2-type spliceosomal >>> complex" then the answer is found via the has_part relation and it's >>> closure. >>> >>> However, this is a different question from "what gene products have been >>> observed to be present in a U2-type spliceosomal complex >>> >>>> [Note that we need to revise the defs of "U2-type spliceosomal complex >>>> ; GO:0005684" (and its sibling "U12-type spliceosomal complex ; >>>> GO:0005689") to be consistent with the def of the parent term >>>> "spliceosomal complex ; GO:0005681" and specify that these terms >>>> represent series of complexes. I'll submit a SF item for this.] >>> >>> https://sourceforge.net/tracker/index.php?func=detail&aid=2843718&group_id=36855&atid=440764 >>> >>> I don't understand the motivation here. I think the definitions should >>> employ a consistent style, but I would change the parent from: >>> >>> GO:0005681 ! spliceosomal complex [DEF: "Any of a series of >>> ribonucleoprotein complexes that... >>> >>> to >>> >>> GO:0005681 ! spliceosomal complex [DEF: "A ribonucleoprotein complex >>> that... >>> >>> I'm not sure how adding "any of a series of..." changes the meaning, it >>> seems to just add extra verbiage that obfuscates the definition. >>> >>> >>> >> >> >> ------------------------------------------------------------------------------ >> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day >> trial. Simplify your report design, integration and deployment - and focus >> on what you do best, core application coding. Discover what's new with >> Crystal Reports now. http://p.sf.net/sfu/bobj-july >> _______________________________________________ >> Geneontology-oboedit-working-group mailing list >> Geneontology-oboedit-working-group at lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/geneontology-oboedit-working-group > > From cjm at berkeleybop.org Tue Sep 1 10:28:53 2009 From: cjm at berkeleybop.org (Chris Mungall) Date: Tue, 1 Sep 2009 10:28:53 -0700 Subject: [Ontology-editors] [OBO-Edit Working Group] displaying has_part In-Reply-To: References: Message-ID: <12E6EEF1-2EBF-4A5A-A83E-346111DCB7FE@berkeleybop.org> Can you explain what you mean by 'ordered series'? On Sep 1, 2009, at 10:24 AM, Karen Christie wrote: > HI David, > > I would think of the major spliceosome (and also the minor and trans > spliceosomes) as an ordered series of complexes, each composed of > some or all of the 5 snRNPs + some other stuff. I don't know that > relates to a "non-contiguous structure". Perhaps you could provide > an example. > > -Karen > > > On Tue, 1 Sep 2009, djs93 at gen.cam.ac.uk wrote: > >> Hi Karen, >> >> I think there might be another way to deal with this issue, that is >> to get a more precise definition of the 'major spliceosome' - one >> that more closely accords with what biologists are actually >> referring too. It seems to me, that the way you use the term is >> most consistent with it referring to a non-contiguous structure - >> by which I mean one whose parts are not all connected to each >> other. As these can be confusing, I think it's important to use >> such terms sparingly, but they are unavoidable in some cases. For >> example, we need terms for functionally defined systems in anatomy. >> Instances of many such systems - e.g.- the immune system or the >> endocrine system, are non-contiguous. Is this the case for what you >> refer to here as the 'major spliceosome'? If so, then, as far as I >> can tell, the original use of part_of in this case was not incorrect. >> >> Hope this helps, rather than just muddying the waters further, >> >> David >> >> On Aug 26 2009, Karen Christie wrote: >> >>> OK, I understand your explanation about "Why should "Queries for >>> U2-type >>> spliceosomal complex should ***not*** return gene products localized >>> to U1 snRNP complex." But I think that is separate from the display >>> issue I have with has_part. >>> However, it also brings up a different issue. A question that a >>> biologist might want to ask is "give me all the proteins in the >>> major >>> spliceosome". They would expect to get the proteins present in the 5 >>> snRNPs (U1, U2, U4, U5, and U6). >> >> >>> By replacing part_of relations with >>> has_part, it seems that they might have difficulty getting a full >>> answer to that question. In your example where g1 is annotated >>> only to >>> "U1 snRNP", you give the hypothetical result: >>> >>>> There are no genes with products known to be localized to >>>> 'U2-type >>>> spliceosomal complex'. >>>> However, every 'U2-type spliceosomal complex' has the >>>> following >>>> parts: >>>> a U1 snRNP -- genes: g1 >>>> a U2 snRNP -- genes: none >>> However, if I wanted to get all proteins in the major spliceosome, I >>> don't want just gene products that are in EVERY 'U2-type >>> spliceosomal >>> complex', I want gene products that are in ANY 'U2-type spliceosomal >>> complex'. What do we need to do to make this a question that >>> biologists >>> get a reasonable answer to? >>> I understand that GO needs to implement more rigorous logic, but >>> if we >>> do it in a way that prevents biologists from getting reasonable >>> answers, we are not doing what we set out to do. >>> -Karen >>> On Mon, 24 Aug 2009, Chris Mungall wrote: >>>> On Aug 24, 2009, at 10:36 AM, Karen Christie wrote: >>>> [snipped part of dialog for now to focus on one issue] >>>>>> I would strongly advocate that even given sufficient developer >>>>>> hours it is better *not* to display the ontology in this way at >>>>>> all. It perhaps looks more comforting, but people will make the >>>>>> same comforting assumptions that no longer hold. For example, >>>>>> it looks like there is some kind of transitive relationship >>>>>> between U1 snRNP and U2-type spliceosomal complex ***which >>>>>> there is not***. It looks like the true path rule might hold. >>>>>> ***it does not*** . Queries for U2-type spliceosomal complex >>>>>> should ***not*** return gene products localized to U1 snRNP >>>>>> complex. >>>>> Why should "Queries for U2-type spliceosomal complex should >>>>> ***not*** >>>>> return gene products localized to U1 snRNP complex."? >>>> OK, good, I think we are circling on on the crux of the issue here. >>>> According to GO, it is not necessarily the case that a gp >>>> localized to a U1 snRNP is necessarily localized to a U2-type >>>> spliceosomal complex. For example, the gp may be localized to a >>>> particular U1 snRNP that is part of a penta-snRNP complex (I may >>>> not have chosen the best example as we're lacking annotations to >>>> this new term, but I can pull out an analogous example if you're >>>> not convinced) >>>> This can be seen in the sub-graph which I reproduce at the end of >>>> this email (let me know if this is not visible in some email >>>> programs, I can make a wiki page with this all on it) - there is >>>> no path following the arrows from U1 snRNP to U2-type >>>> spliceosomal complex. Note that attempting to show the graph in >>>> an "intuitive" way as I have attempted to do below, with the >>>> smaller entities at the bottom, is actually *misleading* because >>>> it leads one to assume that there is some inferred all-some >>>> relationship between these two terms when in fact there is not. >>>> Biology is complex and logic is hard. There's no escaping this. I >>>> don't believe we should simplify either to the point where we get >>>> false positives. I do think we need better ways of displaying >>>> this complex information, but I think we should focus resources >>>> on doing this in end user-facing tools rather than oboedit, as we >>>> would hope everyone using oboedit to edit the ontology would have >>>> an understanding of the logic or a willingness to learn. >>>> Here is a roughly sketched out example of how this could work >>>> Let's say PMID:123 describes an observation of a product of g1 >>>> being localized to a 'U1 snRNP' via an IDA. Let's say that's all >>>> we know, either due to the resolution of the assay or that's all >>>> that the annotator specified. The user queries for 'U2-type >>>> spliceosomal complex' >>>> The query result screen could show something like: >>>> >>>> There are no genes with products known to be localized to 'U2- >>>> type spliceosomal complex'. >>>> However, every 'U2-type spliceosomal complex' has the following >>>> parts: >>>> a U1 snRNP -- genes: g1 >>>> a U2 snRNP -- genes: none >>>> A more advanced tool would be able to show even more: >>>> >>>> PMID:123 shows g1 in U1 snRNP. >>>> prob('U2-type spliceosomal complex') = 0.83 >>>> prob('penta-snRNP complex') = 0.05 >>>> ... >>>> This leads the user to terms of relevance, shows what is known, >>>> shows what might be the case, and does not show anything that is >>>> false. >>>>> I would have >>>>> thought that they should. If I wanted to know the parts of "U2- >>>>> type >>>>> spliceosomal complex" I would want to know all the things that >>>>> compose >>>>> the series of complexes that are all considered to be a "U2-type >>>>> spliceosomal complex". >>>> I'm not sure I really understand the statement, it sounds >>>> tautological, I don't understand what adding "series of" adds. >>>> If the question is "what parts can be found in every U2-type >>>> spliceosomal complex" then the answer is found via the has_part >>>> relation and it's closure. >>>> However, this is a different question from "what gene products >>>> have been observed to be present in a U2-type spliceosomal complex >>>>> [Note that we need to revise the defs of "U2-type spliceosomal >>>>> complex >>>>> ; GO:0005684" (and its sibling "U12-type spliceosomal complex ; >>>>> GO:0005689") to be consistent with the def of the parent term >>>>> "spliceosomal complex ; GO:0005681" and specify that these terms >>>>> represent series of complexes. I'll submit a SF item for this.] >>>> >>>> https://sourceforge.net/tracker/index.php?func=detail&aid=2843718&group_id=36855&atid=440764 >>>> I don't understand the motivation here. I think the definitions >>>> should employ a consistent style, but I would change the parent >>>> from: >>>> GO:0005681 ! spliceosomal complex [DEF: "Any of a series of >>>> ribonucleoprotein complexes that... >>>> to >>>> GO:0005681 ! spliceosomal complex [DEF: "A ribonucleoprotein >>>> complex that... >>>> I'm not sure how adding "any of a series of..." changes the >>>> meaning, it seems to just add extra verbiage that obfuscates the >>>> definition. >>> >>> ------------------------------------------------------------------------------ Let >>> Crystal Reports handle the reporting - Free Crystal Reports 2008 >>> 30-Day trial. Simplify your report design, integration and >>> deployment - and focus on what you do best, core application >>> coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july >>> _______________________________________________ Geneontology- >>> oboedit-working-group mailing list Geneontology-oboedit-working-group at lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/geneontology-oboedit-working-group >> >> > From cjm at berkeleybop.org Tue Sep 1 10:33:18 2009 From: cjm at berkeleybop.org (Chris Mungall) Date: Tue, 1 Sep 2009 10:33:18 -0700 Subject: [Ontology-editors] [OBO-Edit Working Group] displaying has_part In-Reply-To: References: Message-ID: An endocrine system is a non-contiguous entity. For any one instance on an endocrine system (e.g. the endocrine system that is part of me), the individual parts (my pituitary gland, my thymoid gland) are spatially disjoint (non-overlapping) On Sep 1, 2009, at 10:24 AM, Karen Christie wrote: > HI David, > > I would think of the major spliceosome (and also the minor and trans > spliceosomes) as an ordered series of complexes, each composed of > some or all of the 5 snRNPs + some other stuff. I don't know that > relates to a "non-contiguous structure". Perhaps you could provide > an example. > > -Karen > > > On Tue, 1 Sep 2009, djs93 at gen.cam.ac.uk wrote: > >> Hi Karen, >> >> I think there might be another way to deal with this issue, that is >> to get a more precise definition of the 'major spliceosome' - one >> that more closely accords with what biologists are actually >> referring too. It seems to me, that the way you use the term is >> most consistent with it referring to a non-contiguous structure - >> by which I mean one whose parts are not all connected to each >> other. As these can be confusing, I think it's important to use >> such terms sparingly, but they are unavoidable in some cases. For >> example, we need terms for functionally defined systems in anatomy. >> Instances of many such systems - e.g.- the immune system or the >> endocrine system, are non-contiguous. Is this the case for what you >> refer to here as the 'major spliceosome'? If so, then, as far as I >> can tell, the original use of part_of in this case was not incorrect. >> >> Hope this helps, rather than just muddying the waters further, >> >> David >> >> On Aug 26 2009, Karen Christie wrote: >> >>> OK, I understand your explanation about "Why should "Queries for >>> U2-type >>> spliceosomal complex should ***not*** return gene products localized >>> to U1 snRNP complex." But I think that is separate from the display >>> issue I have with has_part. >>> However, it also brings up a different issue. A question that a >>> biologist might want to ask is "give me all the proteins in the >>> major >>> spliceosome". They would expect to get the proteins present in the 5 >>> snRNPs (U1, U2, U4, U5, and U6). >> >> >>> By replacing part_of relations with >>> has_part, it seems that they might have difficulty getting a full >>> answer to that question. In your example where g1 is annotated >>> only to >>> "U1 snRNP", you give the hypothetical result: >>> >>>> There are no genes with products known to be localized to >>>> 'U2-type >>>> spliceosomal complex'. >>>> However, every 'U2-type spliceosomal complex' has the >>>> following >>>> parts: >>>> a U1 snRNP -- genes: g1 >>>> a U2 snRNP -- genes: none >>> However, if I wanted to get all proteins in the major spliceosome, I >>> don't want just gene products that are in EVERY 'U2-type >>> spliceosomal >>> complex', I want gene products that are in ANY 'U2-type spliceosomal >>> complex'. What do we need to do to make this a question that >>> biologists >>> get a reasonable answer to? >>> I understand that GO needs to implement more rigorous logic, but >>> if we >>> do it in a way that prevents biologists from getting reasonable >>> answers, we are not doing what we set out to do. >>> -Karen >>> On Mon, 24 Aug 2009, Chris Mungall wrote: >>>> On Aug 24, 2009, at 10:36 AM, Karen Christie wrote: >>>> [snipped part of dialog for now to focus on one issue] >>>>>> I would strongly advocate that even given sufficient developer >>>>>> hours it is better *not* to display the ontology in this way at >>>>>> all. It perhaps looks more comforting, but people will make the >>>>>> same comforting assumptions that no longer hold. For example, >>>>>> it looks like there is some kind of transitive relationship >>>>>> between U1 snRNP and U2-type spliceosomal complex ***which >>>>>> there is not***. It looks like the true path rule might hold. >>>>>> ***it does not*** . Queries for U2-type spliceosomal complex >>>>>> should ***not*** return gene products localized to U1 snRNP >>>>>> complex. >>>>> Why should "Queries for U2-type spliceosomal complex should >>>>> ***not*** >>>>> return gene products localized to U1 snRNP complex."? >>>> OK, good, I think we are circling on on the crux of the issue here. >>>> According to GO, it is not necessarily the case that a gp >>>> localized to a U1 snRNP is necessarily localized to a U2-type >>>> spliceosomal complex. For example, the gp may be localized to a >>>> particular U1 snRNP that is part of a penta-snRNP complex (I may >>>> not have chosen the best example as we're lacking annotations to >>>> this new term, but I can pull out an analogous example if you're >>>> not convinced) >>>> This can be seen in the sub-graph which I reproduce at the end of >>>> this email (let me know if this is not visible in some email >>>> programs, I can make a wiki page with this all on it) - there is >>>> no path following the arrows from U1 snRNP to U2-type >>>> spliceosomal complex. Note that attempting to show the graph in >>>> an "intuitive" way as I have attempted to do below, with the >>>> smaller entities at the bottom, is actually *misleading* because >>>> it leads one to assume that there is some inferred all-some >>>> relationship between these two terms when in fact there is not. >>>> Biology is complex and logic is hard. There's no escaping this. I >>>> don't believe we should simplify either to the point where we get >>>> false positives. I do think we need better ways of displaying >>>> this complex information, but I think we should focus resources >>>> on doing this in end user-facing tools rather than oboedit, as we >>>> would hope everyone using oboedit to edit the ontology would have >>>> an understanding of the logic or a willingness to learn. >>>> Here is a roughly sketched out example of how this could work >>>> Let's say PMID:123 describes an observation of a product of g1 >>>> being localized to a 'U1 snRNP' via an IDA. Let's say that's all >>>> we know, either due to the resolution of the assay or that's all >>>> that the annotator specified. The user queries for 'U2-type >>>> spliceosomal complex' >>>> The query result screen could show something like: >>>> >>>> There are no genes with products known to be localized to 'U2- >>>> type spliceosomal complex'. >>>> However, every 'U2-type spliceosomal complex' has the following >>>> parts: >>>> a U1 snRNP -- genes: g1 >>>> a U2 snRNP -- genes: none >>>> A more advanced tool would be able to show even more: >>>> >>>> PMID:123 shows g1 in U1 snRNP. >>>> prob('U2-type spliceosomal complex') = 0.83 >>>> prob('penta-snRNP complex') = 0.05 >>>> ... >>>> This leads the user to terms of relevance, shows what is known, >>>> shows what might be the case, and does not show anything that is >>>> false. >>>>> I would have >>>>> thought that they should. If I wanted to know the parts of "U2- >>>>> type >>>>> spliceosomal complex" I would want to know all the things that >>>>> compose >>>>> the series of complexes that are all considered to be a "U2-type >>>>> spliceosomal complex". >>>> I'm not sure I really understand the statement, it sounds >>>> tautological, I don't understand what adding "series of" adds. >>>> If the question is "what parts can be found in every U2-type >>>> spliceosomal complex" then the answer is found via the has_part >>>> relation and it's closure. >>>> However, this is a different question from "what gene products >>>> have been observed to be present in a U2-type spliceosomal complex >>>>> [Note that we need to revise the defs of "U2-type spliceosomal >>>>> complex >>>>> ; GO:0005684" (and its sibling "U12-type spliceosomal complex ; >>>>> GO:0005689") to be consistent with the def of the parent term >>>>> "spliceosomal complex ; GO:0005681" and specify that these terms >>>>> represent series of complexes. I'll submit a SF item for this.] >>>> >>>> https://sourceforge.net/tracker/index.php?func=detail&aid=2843718&group_id=36855&atid=440764 >>>> I don't understand the motivation here. I think the definitions >>>> should employ a consistent style, but I would change the parent >>>> from: >>>> GO:0005681 ! spliceosomal complex [DEF: "Any of a series of >>>> ribonucleoprotein complexes that... >>>> to >>>> GO:0005681 ! spliceosomal complex [DEF: "A ribonucleoprotein >>>> complex that... >>>> I'm not sure how adding "any of a series of..." changes the >>>> meaning, it seems to just add extra verbiage that obfuscates the >>>> definition. >>> >>> ------------------------------------------------------------------------------ Let >>> Crystal Reports handle the reporting - Free Crystal Reports 2008 >>> 30-Day trial. Simplify your report design, integration and >>> deployment - and focus on what you do best, core application >>> coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july >>> _______________________________________________ Geneontology- >>> oboedit-working-group mailing list Geneontology-oboedit-working-group at lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/geneontology-oboedit-working-group >> >> > From rama at genome.stanford.edu Tue Sep 1 11:06:42 2009 From: rama at genome.stanford.edu (Rama Balakrishnan) Date: Tue, 1 Sep 2009 11:06:42 -0700 Subject: [Ontology-editors] [OBO-Edit Working Group] displaying has_part In-Reply-To: References:

Message-ID: I haven't been following the thread completely...so this may sound tangential/ out of place/ irrelevant. Apologies and feel free to ignore this comment if that be the case. Is it possible that the fundamental issue is that we decided to capture protein complexes as cellular component terms but we did not take time to figure out where we should stop or what constitutes a complex (for example, do 3 interacting proteins constitute a complex?). Rama On Sep 1, 2009, at 10:33 AM, Chris Mungall wrote: > > An endocrine system is a non-contiguous entity. For any one instance > on an endocrine system (e.g. the endocrine system that is part of me), > the individual parts (my pituitary gland, my thymoid gland) are > spatially disjoint (non-overlapping) > > On Sep 1, 2009, at 10:24 AM, Karen Christie wrote: > >> HI David, >> >> I would think of the major spliceosome (and also the minor and trans >> spliceosomes) as an ordered series of complexes, each composed of >> some or all of the 5 snRNPs + some other stuff. I don't know that >> relates to a "non-contiguous structure". Perhaps you could provide >> an example. >> >> -Karen >> >> >> On Tue, 1 Sep 2009, djs93 at gen.cam.ac.uk wrote: >> >>> Hi Karen, >>> >>> I think there might be another way to deal with this issue, that is >>> to get a more precise definition of the 'major spliceosome' - one >>> that more closely accords with what biologists are actually >>> referring too. It seems to me, that the way you use the term is >>> most consistent with it referring to a non-contiguous structure - >>> by which I mean one whose parts are not all connected to each >>> other. As these can be confusing, I think it's important to use >>> such terms sparingly, but they are unavoidable in some cases. For >>> example, we need terms for functionally defined systems in anatomy. >>> Instances of many such systems - e.g.- the immune system or the >>> endocrine system, are non-contiguous. Is this the case for what you >>> refer to here as the 'major spliceosome'? If so, then, as far as I >>> can tell, the original use of part_of in this case was not >>> incorrect. >>> >>> Hope this helps, rather than just muddying the waters further, >>> >>> David >>> >>> On Aug 26 2009, Karen Christie wrote: >>> >>>> OK, I understand your explanation about "Why should "Queries for >>>> U2-type >>>> spliceosomal complex should ***not*** return gene products >>>> localized >>>> to U1 snRNP complex." But I think that is separate from the display >>>> issue I have with has_part. >>>> However, it also brings up a different issue. A question that a >>>> biologist might want to ask is "give me all the proteins in the >>>> major >>>> spliceosome". They would expect to get the proteins present in >>>> the 5 >>>> snRNPs (U1, U2, U4, U5, and U6). >>> >>> >>>> By replacing part_of relations with >>>> has_part, it seems that they might have difficulty getting a full >>>> answer to that question. In your example where g1 is annotated >>>> only to >>>> "U1 snRNP", you give the hypothetical result: >>>> >>>>> There are no genes with products known to be localized to >>>>> 'U2-type >>>>> spliceosomal complex'. >>>>> However, every 'U2-type spliceosomal complex' has the >>>>> following >>>>> parts: >>>>> a U1 snRNP -- genes: g1 >>>>> a U2 snRNP -- genes: none >>>> However, if I wanted to get all proteins in the major >>>> spliceosome, I >>>> don't want just gene products that are in EVERY 'U2-type >>>> spliceosomal >>>> complex', I want gene products that are in ANY 'U2-type >>>> spliceosomal >>>> complex'. What do we need to do to make this a question that >>>> biologists >>>> get a reasonable answer to? >>>> I understand that GO needs to implement more rigorous logic, but >>>> if we >>>> do it in a way that prevents biologists from getting reasonable >>>> answers, we are not doing what we set out to do. >>>> -Karen >>>> On Mon, 24 Aug 2009, Chris Mungall wrote: >>>>> On Aug 24, 2009, at 10:36 AM, Karen Christie wrote: >>>>> [snipped part of dialog for now to focus on one issue] >>>>>>> I would strongly advocate that even given sufficient developer >>>>>>> hours it is better *not* to display the ontology in this way at >>>>>>> all. It perhaps looks more comforting, but people will make the >>>>>>> same comforting assumptions that no longer hold. For example, >>>>>>> it looks like there is some kind of transitive relationship >>>>>>> between U1 snRNP and U2-type spliceosomal complex ***which >>>>>>> there is not***. It looks like the true path rule might hold. >>>>>>> ***it does not*** . Queries for U2-type spliceosomal complex >>>>>>> should ***not*** return gene products localized to U1 snRNP >>>>>>> complex. >>>>>> Why should "Queries for U2-type spliceosomal complex should >>>>>> ***not*** >>>>>> return gene products localized to U1 snRNP complex."? >>>>> OK, good, I think we are circling on on the crux of the issue >>>>> here. >>>>> According to GO, it is not necessarily the case that a gp >>>>> localized to a U1 snRNP is necessarily localized to a U2-type >>>>> spliceosomal complex. For example, the gp may be localized to a >>>>> particular U1 snRNP that is part of a penta-snRNP complex (I may >>>>> not have chosen the best example as we're lacking annotations to >>>>> this new term, but I can pull out an analogous example if you're >>>>> not convinced) >>>>> This can be seen in the sub-graph which I reproduce at the end of >>>>> this email (let me know if this is not visible in some email >>>>> programs, I can make a wiki page with this all on it) - there is >>>>> no path following the arrows from U1 snRNP to U2-type >>>>> spliceosomal complex. Note that attempting to show the graph in >>>>> an "intuitive" way as I have attempted to do below, with the >>>>> smaller entities at the bottom, is actually *misleading* because >>>>> it leads one to assume that there is some inferred all-some >>>>> relationship between these two terms when in fact there is not. >>>>> Biology is complex and logic is hard. There's no escaping this. I >>>>> don't believe we should simplify either to the point where we get >>>>> false positives. I do think we need better ways of displaying >>>>> this complex information, but I think we should focus resources >>>>> on doing this in end user-facing tools rather than oboedit, as we >>>>> would hope everyone using oboedit to edit the ontology would have >>>>> an understanding of the logic or a willingness to learn. >>>>> Here is a roughly sketched out example of how this could work >>>>> Let's say PMID:123 describes an observation of a product of g1 >>>>> being localized to a 'U1 snRNP' via an IDA. Let's say that's all >>>>> we know, either due to the resolution of the assay or that's all >>>>> that the annotator specified. The user queries for 'U2-type >>>>> spliceosomal complex' >>>>> The query result screen could show something like: >>>>> >>>>> There are no genes with products known to be localized to 'U2- >>>>> type spliceosomal complex'. >>>>> However, every 'U2-type spliceosomal complex' has the following >>>>> parts: >>>>> a U1 snRNP -- genes: g1 >>>>> a U2 snRNP -- genes: none >>>>> A more advanced tool would be able to show even more: >>>>> >>>>> PMID:123 shows g1 in U1 snRNP. >>>>> prob('U2-type spliceosomal complex') = 0.83 >>>>> prob('penta-snRNP complex') = 0.05 >>>>> ... >>>>> This leads the user to terms of relevance, shows what is known, >>>>> shows what might be the case, and does not show anything that is >>>>> false. >>>>>> I would have >>>>>> thought that they should. If I wanted to know the parts of "U2- >>>>>> type >>>>>> spliceosomal complex" I would want to know all the things that >>>>>> compose >>>>>> the series of complexes that are all considered to be a "U2-type >>>>>> spliceosomal complex". >>>>> I'm not sure I really understand the statement, it sounds >>>>> tautological, I don't understand what adding "series of" adds. >>>>> If the question is "what parts can be found in every U2-type >>>>> spliceosomal complex" then the answer is found via the has_part >>>>> relation and it's closure. >>>>> However, this is a different question from "what gene products >>>>> have been observed to be present in a U2-type spliceosomal complex >>>>>> [Note that we need to revise the defs of "U2-type spliceosomal >>>>>> complex >>>>>> ; GO:0005684" (and its sibling "U12-type spliceosomal complex ; >>>>>> GO:0005689") to be consistent with the def of the parent term >>>>>> "spliceosomal complex ; GO:0005681" and specify that these terms >>>>>> represent series of complexes. I'll submit a SF item for this.] >>>>> >>>>> https://sourceforge.net/tracker/index.php?func=detail&aid=2843718&group_id=36855&atid=440764 >>>>> I don't understand the motivation here. I think the definitions >>>>> should employ a consistent style, but I would change the parent >>>>> from: >>>>> GO:0005681 ! spliceosomal complex [DEF: "Any of a series of >>>>> ribonucleoprotein complexes that... >>>>> to >>>>> GO:0005681 ! spliceosomal complex [DEF: "A ribonucleoprotein >>>>> complex that... >>>>> I'm not sure how adding "any of a series of..." changes the >>>>> meaning, it seems to just add extra verbiage that obfuscates the >>>>> definition. >>>> >>>> ------------------------------------------------------------------------------ Let >>>> Crystal Reports handle the reporting - Free Crystal Reports 2008 >>>> 30-Day trial. Simplify your report design, integration and >>>> deployment - and focus on what you do best, core application >>>> coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july >>>> _______________________________________________ Geneontology- >>>> oboedit-working-group mailing list Geneontology-oboedit-working-group at lists.sourceforge.net >>>> https://lists.sourceforge.net/lists/listinfo/geneontology-oboedit-working-group >>> >>> >> > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 > 30-Day > trial. Simplify your report design, integration and deployment - and > focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Geneontology-oboedit-working-group mailing list > Geneontology-oboedit-working-group at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geneontology-oboedit-working-group From kchris at genome.stanford.edu Tue Sep 1 15:40:42 2009 From: kchris at genome.stanford.edu (Karen Christie) Date: Tue, 1 Sep 2009 15:40:42 -0700 (PDT) Subject: [Ontology-editors] [OBO-Edit Working Group] displaying has_part In-Reply-To: References:

Message-ID: Responding to both of Chris's last two emails together. By comparison with the endocrine system, I don't think the spliceosome can be considered a non-contiguous entity. The situation doesn't seem comparable. Perhaps you'll agree with that once I explain what I mean by 'ordered series', though let me say before I start that I only care about the order as a biologist. GO doesn't represent the order, just all the complexes that are observed. People talk about "the" spliceosome, but there isn't really a single complex that could be referred to as "the spliceosome". Originally, when people first isolated a big ribonucleoprotein complex involved in mRNA splicing, they probably assumed it had a static composition, as seems to be the case for the ribosome. Be that as it may, 5 snRNPs, each containing 1 snRNA (U1, U2, U4, U5, or U6) and a bunch of proteins (a mostly common ring of 7, plus proteins unique to each snRNP), are considered to make up "the spliceosome". For simplicity, I'm just going to use the RNA name, e.g. U1, but when I talk about something like U1, I actually mean the entire snRNP, so the RNA + 9 or more proteins, depending on which one it is. When people study assembly of the spliceosome, it turns out that most people see an ordered assembly pathway as the snRNPs assemble onto the pre-mRNA, rather than an existing "complete spliceosome". Basically, U1 and U2 seem to assemble onto the pre-mRNA, while U4, U5, and U6 form a tri-snRNP called U4/U6.U5. The tri-snRNP U4/U6.U5 joins the other two snRNPs already on the mRNA to form something called the prespliceosome (or A2-1). The prespliceosome is the only complex in the series that contains all 5 snRNPs, but it is NOT catalytic. In order to become catalytic, it undergoes a major conformational change and spits out U1 and U4. So both of the two catalytic conformations (A1 and A2-2) contain U2, U5, and U6, but not U1 or U4. However, a biologist will still want to see the gene products that are in U1 and U4 as spliceosomal proteins because they both play key roles in the process of splicing in the recognition of the splice sites. The GO term used to be named "spliceosome". In the recent component changes that introduced the has_part relationship, we changed the name to "spliceosomal complex" because it is basically a grouping term collecting the various different complexes that are seen in the splicesosome cycle. The pathway is normally drawn as a circular diagram representing the cyclic assembly and disassambly, but for email, here it is as a list: Complex Label (yeast) Constituents ------------- -------------------------------------------- CC U1, pre-mRNA B U1, U2, pre-mRNA U4/U6.U5 U4, U5, U6 A2-1 U1, U2, U4/U6, U5, pre-mRNA (non-catalytic pre-spliceosome) A1 U2, U6, U5, pre-mRNA (catalytic for 1st step) A2-2 U2, U6, U5, 5'exon and lariat RNA (catalytic for 2nd step) A2-3 U2, U6, U5, spliced mRNA and excised lariat RNA I U2, U6, U5, excised lariat RNA Or this version might be more illustrative: Complex some Label (yeast) U1 U2 U4 U5 U6 RNA ------------------------------------------------------------ CC + + B + + + U4/U6.U5 + + + A2-1 + + + + + + A1 + + + + A2-2 + + + + A2-3 + + + + I + + + + -Karen On Tue, 1 Sep 2009, Chris Mungall wrote: > Can you explain what you mean by 'ordered series'? On Tue, 1 Sep 2009, Chris Mungall wrote: > > An endocrine system is a non-contiguous entity. For any one instance on an > endocrine system (e.g. the endocrine system that is part of me), the > individual parts (my pituitary gland, my thymoid gland) are spatially > disjoint (non-overlapping) > > On Sep 1, 2009, at 10:24 AM, Karen Christie wrote: > >> HI David, >> >> I would think of the major spliceosome (and also the minor and trans >> spliceosomes) as an ordered series of complexes, each composed of some or >> all of the 5 snRNPs + some other stuff. I don't know that relates to a >> "non-contiguous structure". Perhaps you could provide an example. >> >> -Karen >> >> >> On Tue, 1 Sep 2009, djs93 at gen.cam.ac.uk wrote: >> >>> Hi Karen, >>> >>> I think there might be another way to deal with this issue, that is to get >>> a more precise definition of the 'major spliceosome' - one that more >>> closely accords with what biologists are actually referring too. It seems >>> to me, that the way you use the term is most consistent with it referring >>> to a non-contiguous structure - by which I mean one whose parts are not >>> all connected to each other. As these can be confusing, I think it's >>> important to use such terms sparingly, but they are unavoidable in some >>> cases. For example, we need terms for functionally defined systems in >>> anatomy. Instances of many such systems - e.g.- the immune system or the >>> endocrine system, are non-contiguous. Is this the case for what you refer >>> to here as the 'major spliceosome'? If so, then, as far as I can tell, the >>> original use of part_of in this case was not incorrect. >>> >>> Hope this helps, rather than just muddying the waters further, >>> >>> David >>> >>> On Aug 26 2009, Karen Christie wrote: >>> >>>> OK, I understand your explanation about "Why should "Queries for U2-type >>>> spliceosomal complex should ***not*** return gene products localized >>>> to U1 snRNP complex." But I think that is separate from the display >>>> issue I have with has_part. >>>> However, it also brings up a different issue. A question that a >>>> biologist might want to ask is "give me all the proteins in the major >>>> spliceosome". They would expect to get the proteins present in the 5 >>>> snRNPs (U1, U2, U4, U5, and U6). >>> >>> >>>> By replacing part_of relations with >>>> has_part, it seems that they might have difficulty getting a full >>>> answer to that question. In your example where g1 is annotated only to >>>> "U1 snRNP", you give the hypothetical result: >>>> >>>>> There are no genes with products known to be localized to 'U2-type >>>>> spliceosomal complex'. >>>>> However, every 'U2-type spliceosomal complex' has the following >>>>> parts: >>>>> a U1 snRNP -- genes: g1 >>>>> a U2 snRNP -- genes: none >>>> However, if I wanted to get all proteins in the major spliceosome, I >>>> don't want just gene products that are in EVERY 'U2-type spliceosomal >>>> complex', I want gene products that are in ANY 'U2-type spliceosomal >>>> complex'. What do we need to do to make this a question that biologists >>>> get a reasonable answer to? >>>> I understand that GO needs to implement more rigorous logic, but if we >>>> do it in a way that prevents biologists from getting reasonable >>>> answers, we are not doing what we set out to do. >>>> -Karen >>>> On Mon, 24 Aug 2009, Chris Mungall wrote: >>>>> On Aug 24, 2009, at 10:36 AM, Karen Christie wrote: >>>>> [snipped part of dialog for now to focus on one issue] >>>>>>> I would strongly advocate that even given sufficient developer hours >>>>>>> it is better *not* to display the ontology in this way at all. It >>>>>>> perhaps looks more comforting, but people will make the same >>>>>>> comforting assumptions that no longer hold. For example, it looks like >>>>>>> there is some kind of transitive relationship between U1 snRNP and >>>>>>> U2-type spliceosomal complex ***which there is not***. It looks like >>>>>>> the true path rule might hold. ***it does not*** . Queries for U2-type >>>>>>> spliceosomal complex should ***not*** return gene products localized >>>>>>> to U1 snRNP complex. >>>>>> Why should "Queries for U2-type spliceosomal complex should ***not*** >>>>>> return gene products localized to U1 snRNP complex."? >>>>> OK, good, I think we are circling on on the crux of the issue here. >>>>> According to GO, it is not necessarily the case that a gp localized to a >>>>> U1 snRNP is necessarily localized to a U2-type spliceosomal complex. For >>>>> example, the gp may be localized to a particular U1 snRNP that is part >>>>> of a penta-snRNP complex (I may not have chosen the best example as >>>>> we're lacking annotations to this new term, but I can pull out an >>>>> analogous example if you're not convinced) >>>>> This can be seen in the sub-graph which I reproduce at the end of this >>>>> email (let me know if this is not visible in some email programs, I can >>>>> make a wiki page with this all on it) - there is no path following the >>>>> arrows from U1 snRNP to U2-type spliceosomal complex. Note that >>>>> attempting to show the graph in an "intuitive" way as I have attempted >>>>> to do below, with the smaller entities at the bottom, is actually >>>>> *misleading* because it leads one to assume that there is some inferred >>>>> all-some relationship between these two terms when in fact there is not. >>>>> Biology is complex and logic is hard. There's no escaping this. I don't >>>>> believe we should simplify either to the point where we get false >>>>> positives. I do think we need better ways of displaying this complex >>>>> information, but I think we should focus resources on doing this in end >>>>> user-facing tools rather than oboedit, as we would hope everyone using >>>>> oboedit to edit the ontology would have an understanding of the logic or >>>>> a willingness to learn. >>>>> Here is a roughly sketched out example of how this could work >>>>> Let's say PMID:123 describes an observation of a product of g1 being >>>>> localized to a 'U1 snRNP' via an IDA. Let's say that's all we know, >>>>> either due to the resolution of the assay or that's all that the >>>>> annotator specified. The user queries for 'U2-type spliceosomal complex' >>>>> The query result screen could show something like: >>>>> >>>>> There are no genes with products known to be localized to 'U2-type >>>>> spliceosomal complex'. >>>>> However, every 'U2-type spliceosomal complex' has the following >>>>> parts: >>>>> a U1 snRNP -- genes: g1 >>>>> a U2 snRNP -- genes: none >>>>> A more advanced tool would be able to show even more: >>>>> >>>>> PMID:123 shows g1 in U1 snRNP. >>>>> prob('U2-type spliceosomal complex') = 0.83 >>>>> prob('penta-snRNP complex') = 0.05 >>>>> ... >>>>> This leads the user to terms of relevance, shows what is known, shows >>>>> what might be the case, and does not show anything that is false. >>>>>> I would have >>>>>> thought that they should. If I wanted to know the parts of "U2-type >>>>>> spliceosomal complex" I would want to know all the things that compose >>>>>> the series of complexes that are all considered to be a "U2-type >>>>>> spliceosomal complex". >>>>> I'm not sure I really understand the statement, it sounds tautological, >>>>> I don't understand what adding "series of" adds. >>>>> If the question is "what parts can be found in every U2-type >>>>> spliceosomal complex" then the answer is found via the has_part relation >>>>> and it's closure. >>>>> However, this is a different question from "what gene products have been >>>>> observed to be present in a U2-type spliceosomal complex >>>>>> [Note that we need to revise the defs of "U2-type spliceosomal complex >>>>>> ; GO:0005684" (and its sibling "U12-type spliceosomal complex ; >>>>>> GO:0005689") to be consistent with the def of the parent term >>>>>> "spliceosomal complex ; GO:0005681" and specify that these terms >>>>>> represent series of complexes. I'll submit a SF item for this.] >>>>> >>>>> https://sourceforge.net/tracker/index.php?func=detail&aid=2843718&group_id=36855&atid=440764 >>>>> I don't understand the motivation here. I think the definitions should >>>>> employ a consistent style, but I would change the parent from: >>>>> GO:0005681 ! spliceosomal complex [DEF: "Any of a series of >>>>> ribonucleoprotein complexes that... >>>>> to >>>>> GO:0005681 ! spliceosomal complex [DEF: "A ribonucleoprotein complex >>>>> that... >>>>> I'm not sure how adding "any of a series of..." changes the meaning, it >>>>> seems to just add extra verbiage that obfuscates the definition. >>>> >>>> ------------------------------------------------------------------------------ >>>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 >>>> 30-Day trial. Simplify your report design, integration and deployment - >>>> and focus on what you do best, core application coding. Discover what's >>>> new with Crystal Reports now. http://p.sf.net/sfu/bobj-july >>>> _______________________________________________ >>>> Geneontology-oboedit-working-group mailing list >>>> Geneontology-oboedit-working-group at lists.sourceforge.net >>>> https://lists.sourceforge.net/lists/listinfo/geneontology-oboedit-working-group >>> >>> > From cjm at berkeleybop.org Tue Sep 1 18:25:24 2009 From: cjm at berkeleybop.org (Chris Mungall) Date: Tue, 1 Sep 2009 18:25:24 -0700 Subject: [Ontology-editors] [OBO-Edit Working Group] displaying has_part In-Reply-To: References:

<9EC14AF7-DE08-41DA-AE09-BC4E5FB3C124@berkeleybop.org> Message-ID: <9AE0D4F8-079E-45CC-BBC3-79EE14798BD0@berkeleybop.org> This is quite annotation-centric but I thought I would discuss this here first. I will talk about this at the meeting. At the last meeting there was some confusion about the F->P part_of links. Annotators were not sure whether they needed to make the redundant annotation to the P from an F annotation for which an F->P direct or indirect link exists. There is no need for annotators to make the redundant annotation. This annotation step can be 100% automated. We do this ahead of time rather than at query time, because some query tools may not be aware of the links (i.e they do not load go_ext because this would break their summary statistics). Here are the results of this automated step: http://www.geneontology.org/scratch/gaf-inference/ Each of these are supplemental GAFs that can be either fed back to the contributors or loaded separately into the GO database. The inferred annotations are treated as ICs, and the F goes in the WITH column. Hopefully this is quite straightforward. More complex are the other non-part_of intra-GO inter-ontology links from the various XP files that will eventually make their way into gene_ontology_write and gene_ontology_ext; for example: > HDAC complex has_function histone deacetylase activity > mitochondrial translation occurs_in mitochondrion > spindle pole body {localization,binding,..} ? spindle pole body > protein import into mitochondrial matrix results_in_transport_to > mitochondrial matrix > etc What are the rules for propagating gene products? We need clear rules here. For example, propagation across occurs_in seems natural - if a gene product participates in P and all the participants of P are located_in C, then P must be localized to C. We can use existing annotations as a guide; but we should do so warily, as there are probably many annotation gaps, just as there are for the F->P links. For any XP relationship that spans 2 GO ontologies we can ask how correlated the resulting annotations are; specifically, if the XP set has a relationship we can ask what is p(target|source). For example, what is the probability of a gene being annotated to 'mitochondrion' if it is annotated to 'mitochondrial translation'? We expect there to be some correlation if the terms are related. In some cases (such as the above) we may expect p ~ 1. The results are in the xps directory - http://www.geneontology.org/scratch/xps/ Look for files *.correl and *correl.avgs here is a summary: > has_participant 0.07145 > results_in_increased_length_of 0.09485 > results_in_change_to 0.1053 > results_in_complete_development_of 0.2023 > results_in_binding_of 0.225558 > results_in_transport_of 0.244143 > results_in_remodeling_of 0.260986 > results_in_transport_along 0.263867 > results_in_breakdown_of 0.30087 > results_in_formation_of 0.305972 > results_in_fusion_of 0.362487 > results_in_organization_of 0.385999 > results_in_connection_of 0.3986 > results_in_transport_to 0.401464 > results_in_morphogenesis_of 0.4231 > results_in_localization_of 0.439052 > results_in_transport_from 0.453718 > results_in_localization_to 0.4632 > unfolds_in 0.486606 > mediated_by 0.487917 > results_in_distribution_of 0.56538 > dependent_on 0.6052 > results_in_transport_involving 0.625 > has_level 0.68916 > realizes 0.695027 > results_in_division_of 0.715433 > has_function 0.718474 > results_in_maturation_of 0.7287 > occurs_in 0.78525 > results_in_transport_towards 0.8027 > results_in_transport_across 0.843125 > part_of-part_of 1.0 results_in_transport_across is high - for example: > GO:0034219-carbohydrate transmembrane transport GO:0016020- > membrane 0.8333 > GO:0034220-ion transmembrane transport GO:0016020-membrane 0.9021 > GO:0055085-transmembrane transport GO:0016020-membrane 0.6857 > GO:0034486-vacuolar transmembrane transport GO:0005774-vacuolar > membrane 1.0000 > GO:0034487-vacuolar amino acid transport GO:0005774-vacuolar > membrane 1.0000 > GO:0034755-iron ion transmembrane transport GO:0016020- > membrane 0.6471 > GO:0034775-glutathione transmembrane transport GO:0016020- > membrane 1.0000 > GO:0065002-intracellular protein transmembrane transport GO: > 0016020-membrane 0.6768 this seems reasonable. if a gene product is involved in X transmembrane transport then there's a good chance it's in the X membrane. I don't think we can say it should *always* be in the X membrane, but there is a good chance it is. This is an example of how the xp sets can be used - to suggest IC annotations to annotators and to make the whole IC system more consistent - to provide users navigational clues (e.g. queries for X transmembrane transport may return fewer results than expected, so the user can be prompted to try a query for X membrane) From djs93 at gen.cam.ac.uk Tue Sep 1 10:15:47 2009 From: djs93 at gen.cam.ac.uk (djs93 at gen.cam.ac.uk) Date: 01 Sep 2009 18:15:47 +0100 Subject: [Ontology-editors] [OBO-Edit Working Group] displaying has_part In-Reply-To: References: Message-ID: Hi Karen, I think there might be another way to deal with this issue, that is to get a more precise definition of the 'major spliceosome' - one that more closely accords with what biologists are actually referring too. It seems to me, that the way you use the term is most consistent with it referring to a non-contiguous structure - by which I mean one whose parts are not all connected to each other. As these can be confusing, I think it's important to use such terms sparingly, but they are unavoidable in some cases. For example, we need terms for functionally defined systems in anatomy. Instances of many such systems - e.g.- the immune system or the endocrine system, are non-contiguous. Is this the case for what you refer to here as the 'major spliceosome'? If so, then, as far as I can tell, the original use of part_of in this case was not incorrect. Hope this helps, rather than just muddying the waters further, David On Aug 26 2009, Karen Christie wrote: >OK, I understand your explanation about "Why should "Queries for U2-type >spliceosomal complex should ***not*** return gene products localized >to U1 snRNP complex." But I think that is separate from the display >issue I have with has_part. > >However, it also brings up a different issue. A question that a >biologist might want to ask is "give me all the proteins in the major >spliceosome". They would expect to get the proteins present in the 5 >snRNPs (U1, U2, U4, U5, and U6). > By replacing part_of relations with >has_part, it seems that they might have difficulty getting a full >answer to that question. In your example where g1 is annotated only to >"U1 snRNP", you give the hypothetical result: > >> There are no genes with products known to be localized to 'U2-type >> spliceosomal complex'. >> However, every 'U2-type spliceosomal complex' has the following >> parts: >> a U1 snRNP -- genes: g1 >> a U2 snRNP -- genes: none > >However, if I wanted to get all proteins in the major spliceosome, I >don't want just gene products that are in EVERY 'U2-type spliceosomal >complex', I want gene products that are in ANY 'U2-type spliceosomal >complex'. What do we need to do to make this a question that biologists >get a reasonable answer to? > >I understand that GO needs to implement more rigorous logic, but if we >do it in a way that prevents biologists from getting reasonable >answers, we are not doing what we set out to do. > >-Karen > > > > >On Mon, 24 Aug 2009, Chris Mungall wrote: > >> >> On Aug 24, 2009, at 10:36 AM, Karen Christie wrote: >> >> [snipped part of dialog for now to focus on one issue] >> >>>> I would strongly advocate that even given sufficient developer hours >>>> it is better *not* to display the ontology in this way at all. It >>>> perhaps looks more comforting, but people will make the same >>>> comforting assumptions that no longer hold. For example, it looks like >>>> there is some kind of transitive relationship between U1 snRNP and >>>> U2-type spliceosomal complex ***which there is not***. It looks like >>>> the true path rule might hold. ***it does not*** . Queries for U2-type >>>> spliceosomal complex should ***not*** return gene products localized >>>> to U1 snRNP complex. >>> >>> Why should "Queries for U2-type spliceosomal complex should ***not*** >>> return gene products localized to U1 snRNP complex."? >> >> OK, good, I think we are circling on on the crux of the issue here. >> >> According to GO, it is not necessarily the case that a gp localized to >> a U1 snRNP is necessarily localized to a U2-type spliceosomal complex. >> For example, the gp may be localized to a particular U1 snRNP that is >> part of a penta-snRNP complex (I may not have chosen the best example as >> we're lacking annotations to this new term, but I can pull out an >> analogous example if you're not convinced) >> >> This can be seen in the sub-graph which I reproduce at the end of this >> email (let me know if this is not visible in some email programs, I can >> make a wiki page with this all on it) - there is no path following the >> arrows from U1 snRNP to U2-type spliceosomal complex. Note that >> attempting to show the graph in an "intuitive" way as I have attempted >> to do below, with the smaller entities at the bottom, is actually >> *misleading* because it leads one to assume that there is some inferred >> all-some relationship between these two terms when in fact there is not. >> >> Biology is complex and logic is hard. There's no escaping this. I don't >> believe we should simplify either to the point where we get false >> positives. I do think we need better ways of displaying this complex >> information, but I think we should focus resources on doing this in end >> user-facing tools rather than oboedit, as we would hope everyone using >> oboedit to edit the ontology would have an understanding of the logic or >> a willingness to learn. >> >> Here is a roughly sketched out example of how this could work >> >> Let's say PMID:123 describes an observation of a product of g1 being >> localized to a 'U1 snRNP' via an IDA. Let's say that's all we know, >> either due to the resolution of the assay or that's all that the >> annotator specified. The user queries for 'U2-type spliceosomal complex' >> >> The query result screen could show something like: >> >> There are no genes with products known to be localized to 'U2-type >> spliceosomal complex'. >> However, every 'U2-type spliceosomal complex' has the following >> parts: >> a U1 snRNP -- genes: g1 >> a U2 snRNP -- genes: none >> >> A more advanced tool would be able to show even more: >> >> PMID:123 shows g1 in U1 snRNP. >> prob('U2-type spliceosomal complex') = 0.83 >> prob('penta-snRNP complex') = 0.05 >> ... >> >> This leads the user to terms of relevance, shows what is known, shows >> what might be the case, and does not show anything that is false. >> >>> I would have >>> thought that they should. If I wanted to know the parts of "U2-type >>> spliceosomal complex" I would want to know all the things that compose >>> the series of complexes that are all considered to be a "U2-type >>> spliceosomal complex". >> >> I'm not sure I really understand the statement, it sounds tautological, >> I don't understand what adding "series of" adds. >> >> If the question is "what parts can be found in every U2-type >> spliceosomal complex" then the answer is found via the has_part relation >> and it's closure. >> >> However, this is a different question from "what gene products have been >> observed to be present in a U2-type spliceosomal complex >> >>> [Note that we need to revise the defs of "U2-type spliceosomal complex >>> ; GO:0005684" (and its sibling "U12-type spliceosomal complex ; >>> GO:0005689") to be consistent with the def of the parent term >>> "spliceosomal complex ; GO:0005681" and specify that these terms >>> represent series of complexes. I'll submit a SF item for this.] >> >> >> >> https://sourceforge.net/tracker/index.php?func=detail&aid=2843718&group_id=36855&atid=440764 >> >> I don't understand the motivation here. I think the definitions should >> employ a consistent style, but I would change the parent from: >> >> GO:0005681 ! spliceosomal complex [DEF: "Any of a series of >> ribonucleoprotein complexes that... >> >> to >> >> GO:0005681 ! spliceosomal complex [DEF: "A ribonucleoprotein complex >> that... >> >> I'm not sure how adding "any of a series of..." changes the meaning, it >> seems to just add extra verbiage that obfuscates the definition. >> >> >> > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 > 30-Day trial. Simplify your report design, integration and deployment - > and focus on what you do best, core application coding. Discover what's > new with Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Geneontology-oboedit-working-group mailing list > Geneontology-oboedit-working-group at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geneontology-oboedit-working-group From midori at ebi.ac.uk Thu Sep 3 07:21:42 2009 From: midori at ebi.ac.uk (Midori Harris) Date: Thu, 3 Sep 2009 15:21:42 +0100 (BST) Subject: [Ontology-editors] filter obsoletes from ec2go? Message-ID: Hi Dan, We've had a SF item with a query about obsolete GO terms/IDs appearing in the ec2go file. I found an email from last year in which Chris said he prefers to keep the EC dbxrefs for obsolete terms (even though the set isn't complete because we'd removed some in the past). But I don't think obsoletes should get into the ec2go file, so can they be skipped/filtered out when ec2go is parsed from the GO .obo file? Thanks, m From jane at ebi.ac.uk Thu Sep 3 07:23:02 2009 From: jane at ebi.ac.uk (Jane Lomax) Date: Thu, 03 Sep 2009 15:23:02 +0100 Subject: [Ontology-editors] XP docs In-Reply-To: References: