GMOD › Chado

Storing GO annotation extensions in Chado

Classic

List

Threaded

12 messages Options

Kim Rutherford

Storing GO annotation extensions in Chado

Hi.

We are in the process of loading the S. pombe GO annotation into a
Chado database. We are looking for suggestions on how to store the new
annotation extensions:
http://wiki.geneontology.org/index.php/Annotation_Cross_Products

Is anyone doing this already? Is anyone planning to do it? We'd
appreciate any advice.

Thanks in advance.

Kim.

------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema

Daniel Quest

Re: Storing GO annotation extensions in Chado

Hi Kim,

Have not seen any replies on this, so I thought I would throw out a crazy idea. Please keep in mind that I am not doing this on my project so I provide this to the list only as a model for the worst idea ever so that someone can come up with something better ;).

First every time an annotator makes an annotation, store it as a feature in the feature table of type 'annotation_event'. The annotation_event is a child of the feature it is annotating. The annotation event is associated with the primary CVterm. The annotation extension (or really any additional features describing the annotation event further) are then stored as child features of the annotation event, each with their own CVterms.

Like I said, don't have a running system working with these things, so I can't give you any feedback on how the solution would perform in the wild. I assume Chris M. already implemented something ???

-Daniel

P.S. I am trying to place your name because I know I have seen it, I think you wrote major parts of artemis? --I think I encountered you in a read of the source code. Awesome work if I am correct in my memory!

On Fri, Jul 8, 2011 at 10:16 AM, Kim Rutherford <[hidden email]> wrote:

Hi.

We are in the process of loading the S. pombe GO annotation into a
Chado database. We are looking for suggestions on how to store the new
annotation extensions:
http://wiki.geneontology.org/index.php/Annotation_Cross_Products

Is anyone doing this already? Is anyone planning to do it? We'd
appreciate any advice.

Thanks in advance.

Kim.

------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema

------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema

Kim Rutherford

Re: Storing GO annotation extensions in Chado

On Friday 8 July 2011 at 23:05:14, Daniel Quest wrote:

> Hi Kim,
>
> Have not seen any replies on this, so I thought I would throw out a crazy
> idea. Please keep in mind that I am not doing this on my project so I
> provide this to the list only as a model for the worst idea ever so that
> someone can come up with something better ;).
>
> First every time an annotator makes an annotation, store it as a feature in
> the feature table of type 'annotation_event'. The annotation_event is a
> child of the feature it is annotating. The annotation event is associated
> with the primary CVterm. The annotation extension (or really any additional
> features describing the annotation event further) are then stored as child
> features of the annotation event, each with their own CVterms.
>
> Like I said, don't have a running system working with these things, so I
> can't give you any feedback on how the solution would perform in the wild.
> I assume Chris M. already implemented something ???

Hi Daniel.

Thanks for your reply. I hadn't considered using the feature table
like that. I guess a down side is that it makes querying a bit more
complicated.

Another possibility that I found with Google after posting my question
is to post-compose a new term as described here:
http://gmod.org/wiki/Chado_CV_Module#Post-coordinating_Terms
and then to annotate with the new term instead.

Unfortunately, the post-composition method seems a bit opaque to me.
And again it would possibly make querying more complicated. Perhaps
that's unavoidable though.

I'd love to see an example of the post-composition method.

> P.S. I am trying to place your name because I know I have seen it, I
> think you wrote major parts of artemis? --I think I encountered you
> in a read of the source code. Awesome work if I am correct in my
> memory!

Thanks! I did work on Artemis many years ago. It has gained a lot of
functionality since then - including Chado support.

Kim.

------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema

Daniel Quest

Re: Storing GO annotation extensions in Chado

Hi Kim,

Yah, that makes sense to me also. Basically the cvterm relationship table serves the same function as the feature relationship table in my previous e-mail. sounds workable.

If I understand it correctly,

anonymous_cv ~= annotation_event

Semantically they are actually different, but functionally they are very similar ideas. In post-coordination/post-composition it looks like you:
1) make a new CVTERM, this belongs to the 'internal' ontology
2) create the relationships between this new CVTERM and existing ontology terms (not sure how the solution deals with CVTERMPath/Transitive closure)
3) If GO or some other ontology is updated to include the new concept, then the new concept is mapped at a later time to this concept (not sure if this is a manual or automated process)

I suppose CJM = Chris Mungall so he is probably the author of this page. He could probably clear all this up.

Thanks
-Daniel

On Mon, Jul 11, 2011 at 9:10 AM, Kim Rutherford <[hidden email]> wrote:

On Friday 8 July 2011 at 23:05:14, Daniel Quest wrote:

> Hi Kim,
>
> Have not seen any replies on this, so I thought I would throw out a crazy
> idea. Please keep in mind that I am not doing this on my project so I
> provide this to the list only as a model for the worst idea ever so that
> someone can come up with something better ;).
>
> First every time an annotator makes an annotation, store it as a feature in
> the feature table of type 'annotation_event'. The annotation_event is a
> child of the feature it is annotating. The annotation event is associated
> with the primary CVterm. The annotation extension (or really any additional
> features describing the annotation event further) are then stored as child
> features of the annotation event, each with their own CVterms.
>
> Like I said, don't have a running system working with these things, so I
> can't give you any feedback on how the solution would perform in the wild.
> I assume Chris M. already implemented something ???

Hi Daniel.

Thanks for your reply. I hadn't considered using the feature table
like that. I guess a down side is that it makes querying a bit more
complicated.

Another possibility that I found with Google after posting my question
is to post-compose a new term as described here:
http://gmod.org/wiki/Chado_CV_Module#Post-coordinating_Terms
and then to annotate with the new term instead.

Unfortunately, the post-composition method seems a bit opaque to me.
And again it would possibly make querying more complicated. Perhaps
that's unavoidable though.

I'd love to see an example of the post-composition method.

> P.S. I am trying to place your name because I know I have seen it, I
> think you wrote major parts of artemis? --I think I encountered you
> in a read of the source code. Awesome work if I am correct in my
> memory!

Thanks! I did work on Artemis many years ago. It has gained a lot of
functionality since then - including Chado support.

Kim.

Siddhartha Basu

Re: Storing GO annotation extensions in Chado

Hi folks,
Seems to be a workable idea to model annotation cross products. Let me
retiterate the idea that i have understood with an example. So for this GAF annotation,
col 5: GO:0005730 ! nucleolus
col 16: part_of(MA:0000198)
[cerebellum from mouse anatomy ontology]

* First we create a cvterm
cvterm.name => 'restriction--part_of--cerebellum' (cv.name =>
anonymous_cv)
dbxref.accession => MA:0000198 (db.name => internal)
* Create a cvterm_relationship
object_id => from MA:0000198 (that ontology has to be loaded before)
type_id => from part_of relation term
subject_id => the above anonymous term
Is there anything i am missing above or got it wrong?

Now how to connect this to the GAF(GO:0005730) line modeled in feature_cvterm table.
One could be through feature_cvtermprop
type_id => cvterm_id of that anonymous term just created.
value => 'cross products'
OR
feature_cvterm_dbxref
dbxref_id => dbxref_id of the anonymous term

I would prefer the feature_cvtermprop though, we could filter for the
cross products.

Anyway, kim if you settle down on a particular model let us know about
it, i would add that model in my GAF loading script.

thanks,
-siddhartha

On Mon, 11 Jul 2011, Daniel Quest wrote:

> Hi Kim,
>
> Yah, that makes sense to me also. Basically the cvterm relationship table
> serves the same function as the feature relationship table in my previous
> e-mail. sounds workable.
>
> If I understand it correctly,
>
> anonymous_cv ~= annotation_event
>
> Semantically they are actually different, but functionally they are very
> similar ideas. In post-coordination/post-composition it looks like you:
> 1) make a new CVTERM, this belongs to the 'internal' ontology
> 2) create the relationships between this new CVTERM and existing ontology
> terms (not sure how the solution deals with CVTERMPath/Transitive closure)
> 3) If GO or some other ontology is updated to include the new concept,
> then the new concept is mapped at a later time to this concept (not sure
> if this is a manual or automated process)
>
> I suppose CJM = Chris Mungall so he is probably the author of this page.
> He could probably clear all this up.
>
> Thanks
> -Daniel
>
> On Mon, Jul 11, 2011 at 9:10 AM, Kim Rutherford <[hidden email]> wrote:
>
> On Friday 8 July 2011 at 23:05:14, Daniel Quest wrote:
>
> > Hi Kim,
> >
> > Have not seen any replies on this, so I thought I would throw out a
> crazy
> > idea. Please keep in mind that I am not doing this on my project so I
> > provide this to the list only as a model for the worst idea ever so
> that
> > someone can come up with something better ;).
> >
> > First every time an annotator makes an annotation, store it as a
> feature in
> > the feature table of type 'annotation_event'. The annotation_event is
> a
> > child of the feature it is annotating. The annotation event is
> associated
> > with the primary CVterm. The annotation extension (or really any
> additional
> > features describing the annotation event further) are then stored as
> child
> > features of the annotation event, each with their own CVterms.
> >
> > Like I said, don't have a running system working with these things, so
> I
> > can't give you any feedback on how the solution would perform in the
> wild.
> > I assume Chris M. already implemented something ???
>
> Hi Daniel.
>
> Thanks for your reply. I hadn't considered using the feature table
> like that. I guess a down side is that it makes querying a bit more
> complicated.
>
> Another possibility that I found with Google after posting my question
> is to post-compose a new term as described here:
> http://gmod.org/wiki/Chado_CV_Module#Post-coordinating_Terms
> and then to annotate with the new term instead.
>
> Unfortunately, the post-composition method seems a bit opaque to me.
> And again it would possibly make querying more complicated. Perhaps
> that's unavoidable though.
>
> I'd love to see an example of the post-composition method.
>
> > P.S. I am trying to place your name because I know I have seen it, I
> > think you wrote major parts of artemis? --I think I encountered you
> > in a read of the source code. Awesome work if I am correct in my
> > memory!
>
> Thanks! I did work on Artemis many years ago. It has gained a lot of
> functionality since then - including Chado support.
> Kim.

> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________
> Gmod-schema mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gmod-schema

Daniel Quest

Re: Storing GO annotation extensions in Chado

Thanks for the awesome example!

On Monday, July 11, 2011, Siddhartha Basu <[hidden email]> wrote:

> Hi folks,
> Seems to be a workable idea to model annotation cross products. Let me
> retiterate the idea that i have understood with an example. So for this GAF annotation,
> col 5: GO:0005730 ! nucleolus
> col 16: part_of(MA:0000198)
> [cerebellum from mouse anatomy ontology]
>
> * First we create a cvterm
>    cvterm.name => 'restriction--part_of--cerebellum' (cv.name =>
>    anonymous_cv)
>   dbxref.accession => MA:0000198 (db.name => internal)
> * Create a cvterm_relationship
>   object_id => from MA:0000198 (that ontology has to be loaded before)
>   type_id => from part_of relation term
>   subject_id => the above anonymous term
> Is there anything i am missing above or got it wrong?
>
>
> Now how to connect this to the GAF(GO:0005730) line modeled in feature_cvterm table.
> One could be through feature_cvtermprop
> type_id => cvterm_id of that anonymous term just created.
> value => 'cross products'
> OR
> feature_cvterm_dbxref
> dbxref_id => dbxref_id of the anonymous term
>
> I would prefer the feature_cvtermprop though, we could filter for the
> cross products.
>
> Anyway, kim if you settle down on a particular model let us know about
> it, i would add that model in my GAF loading script.
>
> thanks,
> -siddhartha
>
>
>
> On Mon, 11 Jul 2011, Daniel Quest wrote:
>
>> Hi Kim,
>>
>> Yah, that makes sense to me also. Basically the cvterm relationship table
>> serves the same function as the feature relationship table in my previous
>> e-mail. sounds workable.
>>
>> If I understand it correctly,
>>
>> anonymous_cv ~= annotation_event
>>
>> Semantically they are actually different, but functionally they are very
>> similar ideas. In post-coordination/post-composition it looks like you:
>> 1) make a new CVTERM, this belongs to the 'internal' ontology
>> 2) create the relationships between this new CVTERM and existing ontology
>> terms (not sure how the solution deals with CVTERMPath/Transitive closure)
>> 3) If GO or some other ontology is updated to include the new concept,
>> then the new concept is mapped at a later time to this concept (not sure
>> if this is a manual or automated process)
>>
>> I suppose CJM = Chris Mungall so he is probably the author of this page.
>> He could probably clear all this up.
>>
>> Thanks
>> -Daniel
>>
>> On Mon, Jul 11, 2011 at 9:10 AM, Kim Rutherford <[hidden email]> wrote:
>>
>> On Friday 8 July 2011 at 23:05:14, Daniel Quest wrote:
>>
>> > Hi Kim,
>> >
>> > Have not seen any replies on this, so I thought I would throw out a
>> crazy
>> > idea. Please keep in mind that I am not doing this on my project so I
>> > provide this to the list only as a model for the worst idea ever so
>> that
>> > someone can come up with something better ;).
>> >
>> > First every time an annotator makes an annotation, store it as a
>> feature in
>> > the feature table of type 'annotation_event'. The annotation_event is
>> a
>> > child of the feature it is annotating. The annotation event is
>> associated
>> > with the primary CVterm. The annotation extension (or really any
>> additional
>> > features describing the annotation event further) are then stored as
>> child
>> > features of the annotation event, each with their own CVterms.
>> >
>> > Like I said, don't have a running system working with these things, so
>> I
>> > can't give you any feedback on how the solution would perform in the
>> wild.
>> > I assume Chris M. already implemented something ???
>>
>> Hi Daniel.
>>
>> Thanks for your reply. I hadn't considered using the feature table
>> like that. I guess a down side is that it makes querying a bit more
>> complicated.
>>
>> Another possibility that I found with Google after posting my question
>> is to post-compose a new term as described here:
>> http://gmod.org/wiki/Chado_CV_Module#Post-coordinating_Terms
>> and then to annotate with the new term instead.
>>
>> Unfortunately, the post-composition method seems a bit opaque to me.
>> And again it would possibly make querying more complicated. Perhaps
>> that's unavoidable though.
>>
>> I'd love to see an example of the post-composition method.
>>
>> > P.S. I am trying to place your name because I know I have seen it, I
>> > think you wrote major parts of artemis? --I think I encountered you
>> > in a read of the source code. Awesome work if I am correct in my
>> > memory!
>>
>> Thanks! I did work on Artemis many years ago. It has gained a lot of
>> functionality since then - including Chado support.
>> Kim.
>
>> ------------------------------------------------------------------------------
>> All of the data generated in your IT infrastructure is seriously valuable.
>> Why? It contains a definitive record of application performance, security
>> threats, fraudulent activity, and more. Splunk takes this data and makes
>> sense of it. IT sense. And common sense.
>> http://p.sf.net/sfu/splunk-d2d-c2
>> _______________________________________________
>> Gmod-schema mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/gmod-schema
>
>
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________
> Gmod-schema mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gmod-schema
>

------------------------------------------------------------------------------
AppSumo Presents a FREE Video for the SourceForge Community by Eric
Ries, the creator of the Lean Startup Methodology on "Lean Startup
Secrets Revealed." This video shows you how to validate your ideas,
optimize your ideas and identify your business strategy.
http://p.sf.net/sfu/appsumosfdev2dev
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema

Chris Mungall

Re: Storing GO annotation extensions in Chado

In reply to this post by Siddhartha Basu

Hi all

Let me start with an example similar to Sidd's, for an annotation of
gene product "G":

col 5: GO:0005737 ! cytoplasm
col 16: part_of(CL:0000654) ! primary oocyte

This would be equivalent to a pre-composed term named "primary oocyte
cytoplasm", were such a term to be materialized in the ontology.

Now imagine we have the more general term "oocyte cytoplasm"
pre-composed in the ontology. Any queries for "oocyte cytoplasm" must
return G - This is a minimal requirement for a query system that can
handle post-composed annotations.

First off, what is the procedure for calculating the correct answer?
This relies on the ontology including a computable definition of the
pre-composed term "oocyte cytoplasm":

id: GO:1234567
name: oocyte cytoplasm
intersection_of: GO:0005737 ! cytoplasm
intersection_of: part_of CL:0000023 ! oocyte

This states that the class "oocyte cytoplasm" is equivalent to
anything that is both a "cytoplasm" and part of an "oocyte". Together
with the trivial link between "primary oocyte" and "oocyte" in CL,
this is enough for a basic reasoner to compute the right answer. The
same reasoner should be able to handle more complex examples.

The reasoning step should probably happen in a Chado-independent
tool. The original post-composition proposal tried to cram everything
in the ontology into Chado, hence the baroqueness. It's more realistic
to focus on modeling the annotation without loss and have the tools
consult an external obo or owl file to get the information required
for reasoning (people generally use Chado as a primary annotation
store, but not a primary ontology store).

With that in mind, I can see two choices:

(1) Sidd's proposal, which mirrors the GAF format and involves an
additional feature_cvtermprop. Here the relationship is modeled as an
anonymous class.

One minor disadvantage here is that we cannot use the cvtermpath table
to store the pre-computed inferences (such as the subsumption
relationship between the post-composed "primary oocyte cytoplasm" and
"oocyte cytoplasm"). This is circumvented by adding a second,
inferred, feature_cvterm row, but this would be a hitherto
non-standard use of this table.

This may or may not matter depending on how Chado is being used. If it
is just a feed for a query engine that handles the inference
separately, it's not a concern.

(2) A simpler version of the original post-composition proposal. Here
the feature_cvterm would be directly to an anonymous cvterm which
would have two cvterm_relationships:

<anon> is_a GO:0005737 ! cytoplasm
<anon> part_of CL:0000654 ! primary oocyte

We would then have an inferred relationship between this and the
pre-composed "occyte cytoplasm" directly in cvtermpath. There are
different schemes for creating the anonymous dbxref:acc pairing (and a
placeholder name).

This model can be applied anywhere ontologies are used. The schema
would be completely neutral w.r.t pre vs post composition.

The problem here is that applications have to do extra work to avoid
exposing the anonymous cvterms in places where they might confuse or
annoy a user. This is harder for pre-existing applications. It's
possible to auto-name the anonymous cvterms but there are still
usability costs to exposing them in the same way as pre-composed
terms. With proposal (1) an application that is completely unaware of
post-compostion and doesn't know how ot handle Sidd's proposal will
show answers that are correct in an intuitive way, but the additional
info is lost.

Note the assumption in both cases is that the full ontology is NOT
being modeled in Chado with complete fidelity. This is becoming
increasingly difficult to do as languages become more expressive. The
baroque layering approach Kim mentioned should be reasonably
future-proof as it's based on the layering of RDF onto OWL, but there
is a price in complexity. You could buy additional expressivity by
adding a flag for stating that a set of relationships constitute
necessary and sufficient conditions.

See for example the 'completes' flag in the GO db:
http://www.geneontology.org/GO.database.schema.shtml#go-graph.table.term2term

This is enough for many obo ontologies, and gives you enough to do the
basic reasoning required for the use case above using only information
stored in the db. But that may not be the ideal strategy - better to
use external tools and pull in the ontology separately.

On Jul 11, 2011, at 10:14 AM, Siddhartha Basu wrote:

> Hi folks,
> Seems to be a workable idea to model annotation cross products. Let me
> retiterate the idea that i have understood with an example. So for this GAF annotation,
> col 5: GO:0005730 ! nucleolus
> col 16: part_of(MA:0000198)
> [cerebellum from mouse anatomy ontology]
>
> * First we create a cvterm
> cvterm.name => 'restriction--part_of--cerebellum' (cv.name =>
> anonymous_cv)
> dbxref.accession => MA:0000198 (db.name => internal)
> * Create a cvterm_relationship
> object_id => from MA:0000198 (that ontology has to be loaded before)
> type_id => from part_of relation term
> subject_id => the above anonymous term
> Is there anything i am missing above or got it wrong?
>
>
> Now how to connect this to the GAF(GO:0005730) line modeled in feature_cvterm table.
> One could be through feature_cvtermprop
> type_id => cvterm_id of that anonymous term just created.
> value => 'cross products'
> OR
> feature_cvterm_dbxref
> dbxref_id => dbxref_id of the anonymous term
>
> I would prefer the feature_cvtermprop though, we could filter for the
> cross products.
>
> Anyway, kim if you settle down on a particular model let us know about
> it, i would add that model in my GAF loading script.
>
> thanks,
> -siddhartha
>
>
>
> On Mon, 11 Jul 2011, Daniel Quest wrote:
>
>> Hi Kim,
>>
>> Yah, that makes sense to me also. Basically the cvterm relationship table
>> serves the same function as the feature relationship table in my previous
>> e-mail. sounds workable.
>>
>> If I understand it correctly,
>>
>> anonymous_cv ~= annotation_event
>>
>> Semantically they are actually different, but functionally they are very
>> similar ideas. In post-coordination/post-composition it looks like you:
>> 1) make a new CVTERM, this belongs to the 'internal' ontology
>> 2) create the relationships between this new CVTERM and existing ontology
>> terms (not sure how the solution deals with CVTERMPath/Transitive closure)
>> 3) If GO or some other ontology is updated to include the new concept,
>> then the new concept is mapped at a later time to this concept (not sure
>> if this is a manual or automated process)
>>
>> I suppose CJM = Chris Mungall so he is probably the author of this page.
>> He could probably clear all this up.
>>
>> Thanks
>> -Daniel
>>
>> On Mon, Jul 11, 2011 at 9:10 AM, Kim Rutherford <[hidden email]> wrote:
>>
>> On Friday 8 July 2011 at 23:05:14, Daniel Quest wrote:
>>
>>> Hi Kim,
>>>
>>> Have not seen any replies on this, so I thought I would throw out a
>> crazy
>>> idea. Please keep in mind that I am not doing this on my project so I
>>> provide this to the list only as a model for the worst idea ever so
>> that
>>> someone can come up with something better ;).
>>>
>>> First every time an annotator makes an annotation, store it as a
>> feature in
>>> the feature table of type 'annotation_event'. The annotation_event is
>> a
>>> child of the feature it is annotating. The annotation event is
>> associated
>>> with the primary CVterm. The annotation extension (or really any
>> additional
>>> features describing the annotation event further) are then stored as
>> child
>>> features of the annotation event, each with their own CVterms.
>>>
>>> Like I said, don't have a running system working with these things, so
>> I
>>> can't give you any feedback on how the solution would perform in the
>> wild.
>>> I assume Chris M. already implemented something ???
>>
>> Hi Daniel.
>>
>> Thanks for your reply. I hadn't considered using the feature table
>> like that. I guess a down side is that it makes querying a bit more
>> complicated.
>>
>> Another possibility that I found with Google after posting my question
>> is to post-compose a new term as described here:
>> http://gmod.org/wiki/Chado_CV_Module#Post-coordinating_Terms
>> and then to annotate with the new term instead.
>>
>> Unfortunately, the post-composition method seems a bit opaque to me.
>> And again it would possibly make querying more complicated. Perhaps
>> that's unavoidable though.
>>
>> I'd love to see an example of the post-composition method.
>>
>>> P.S. I am trying to place your name because I know I have seen it, I
>>> think you wrote major parts of artemis? --I think I encountered you
>>> in a read of the source code. Awesome work if I am correct in my
>>> memory!
>>
>> Thanks! I did work on Artemis many years ago. It has gained a lot of
>> functionality since then - including Chado support.
>> Kim.
>
>> ------------------------------------------------------------------------------
>> All of the data generated in your IT infrastructure is seriously valuable.
>> Why? It contains a definitive record of application performance, security
>> threats, fraudulent activity, and more. Splunk takes this data and makes
>> sense of it. IT sense. And common sense.
>> http://p.sf.net/sfu/splunk-d2d-c2
>> _______________________________________________
>> Gmod-schema mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/gmod-schema
>
>
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________
> Gmod-schema mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gmod-schema

Kim Rutherford

Re: Storing GO annotation extensions in Chado

In reply to this post by Daniel Quest

On Monday 11 July 2011 at 10:44:24, Daniel Quest wrote:

> Semantically they are actually different, but functionally they are very
> similar ideas. In post-coordination/post-composition it looks like you:
> 1) make a new CVTERM, this belongs to the 'internal' ontology
> 2) create the relationships between this new CVTERM and existing ontology
> terms (not sure how the solution deals with CVTERMPath/Transitive
> closure)

Updating cvtermpath is an extra maintenance step that is a bit of a
down side to post-composing.

> 3) If GO or some other ontology is updated to include the new
> concept, then the new concept is mapped at a later time to this
> concept (not sure if this is a manual or automated process)

Yep, good point. Hopefully it will be possible for new GO term to be
automatically suggested as a replacement for the old term + annotation
extension. Again, there's a little bit of maintenance involved in
Chado.

Kim.

------------------------------------------------------------------------------
AppSumo Presents a FREE Video for the SourceForge Community by Eric
Ries, the creator of the Lean Startup Methodology on "Lean Startup
Secrets Revealed." This video shows you how to validate your ideas,
optimize your ideas and identify your business strategy.
http://p.sf.net/sfu/appsumosfdev2dev
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema

Kim Rutherford

Re: Storing GO annotation extensions in Chado, Re: Storing GO annotation extensions in Chado

In reply to this post by Siddhartha Basu

On Monday 11 July 2011 at 12:14:35, Siddhartha Basu wrote:

> Anyway, kim if you settle down on a particular model let us know about
> it, i would add that model in my GAF loading script.

Thanks.

On Tuesday 12 July 2011 at 21:00:00, Chris Mungall wrote:

> This states that the class "oocyte cytoplasm" is equivalent to
> anything that is both a "cytoplasm" and part of an "oocyte". Together
> with the trivial link between "primary oocyte" and "oocyte" in CL,
> this is enough for a basic reasoner to compute the right answer. The
> same reasoner should be able to handle more complex examples.

Thanks for the example.

> With that in mind, I can see two choices:
>
> (2) A simpler version of the original post-composition proposal.

I think I'll give this suggestion a try. It's less opaque than the
original post-composition proposal, but it's still relatively
computable and queryable.

One thing that hasn't been discussed is the case where an annotation
extension refers to a feature. An example from Val's annotation might
be:

G has "protein kinase activity" target_is("SPBC11B10.09")

The feature uniquename could be stored as a cvtermprop of the anonymous
term, but it would be nice if the anonymous cvterm could refer to the
feature as a foreign key. As that would require an extra table I think
I'm happy to use cvtermprop for now.

Thanks Daniel, Sidd and Chris for your replies. I'll report back once
I've tried implementing (2).

Kim.

------------------------------------------------------------------------------
AppSumo Presents a FREE Video for the SourceForge Community by Eric
Ries, the creator of the Lean Startup Methodology on "Lean Startup
Secrets Revealed." This video shows you how to validate your ideas,
optimize your ideas and identify your business strategy.
http://p.sf.net/sfu/appsumosfdev2dev
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema

Kim Rutherford

Re: Storing GO annotation extensions in Chado, Re: Storing GO annotation extensions in Chado

On Wednesday 13 July 2011 at 16:25:18, Kim Rutherford wrote:

> > With that in mind, I can see two choices:
> >
> > (2) A simpler version of the original post-composition proposal.
>
> I think I'll give this suggestion a try. It's less opaque than the
> original post-composition proposal, but it's still relatively
> computable and queryable.
>
> ...
>
> Thanks Daniel, Sidd and Chris for your replies. I'll report back once
> I've tried implementing (2).

The pombe annotation extensions are now loaded, using plan (2). The
results are here if anyone is interested:
http://sloth.sysbiol.cam.ac.uk/~kmr44/dumps/current.dump.gz

Thanks for you help.

Kim.

------------------------------------------------------------------------------
BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
The must-attend event for mobile developers. Connect with experts.
Get tools for creating Super Apps. See the latest technologies.
Sessions, hands-on labs, demos & much more. Register early & save!
http://p.sf.net/sfu/rim-blackberry-1
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema

Daniel Quest

Re: Storing GO annotation extensions in Chado, Re: Storing GO annotation extensions in Chado

Awesome!

On Wed, Aug 3, 2011 at 8:27 AM, Kim Rutherford <[hidden email]> wrote:

> On Wednesday 13 July 2011 at 16:25:18, Kim Rutherford wrote:
>
>> > With that in mind, I can see two choices:
>> >
>> > (2) A simpler version of the original post-composition proposal.
>>
>> I think I'll give this suggestion a try. It's less opaque than the
>> original post-composition proposal, but it's still relatively
>> computable and queryable.
>>
>> ...
>>
>> Thanks Daniel, Sidd and Chris for your replies. I'll report back once
>> I've tried implementing (2).
>
> The pombe annotation extensions are now loaded, using plan (2). The
> results are here if anyone is interested:
> http://sloth.sysbiol.cam.ac.uk/~kmr44/dumps/current.dump.gz
>
> Thanks for you help.
>
> Kim.
>
> ------------------------------------------------------------------------------
> BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
> The must-attend event for mobile developers. Connect with experts.
> Get tools for creating Super Apps. See the latest technologies.
> Sessions, hands-on labs, demos & much more. Register early & save!
> http://p.sf.net/sfu/rim-blackberry-1
> _______________________________________________
> Gmod-schema mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gmod-schema
>

------------------------------------------------------------------------------
BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
The must-attend event for mobile developers. Connect with experts.
Get tools for creating Super Apps. See the latest technologies.
Sessions, hands-on labs, demos & much more. Register early & save!
http://p.sf.net/sfu/rim-blackberry-1
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema

Siddhartha Basu

Re: Storing GO annotation extensions in Chado, Re: Storing GO annotation extensions in Chado

In reply to this post by Kim Rutherford

Great!!!
Would check out the dump when i get a chance.

thanks,
-siddhartha

On Wed, 03 Aug 2011, Kim Rutherford wrote:

> On Wednesday 13 July 2011 at 16:25:18, Kim Rutherford wrote:
>
> > > With that in mind, I can see two choices:
> > >
> > > (2) A simpler version of the original post-composition proposal.
> >
> > I think I'll give this suggestion a try. It's less opaque than the
> > original post-composition proposal, but it's still relatively
> > computable and queryable.
> >
> > ...
> >
> > Thanks Daniel, Sidd and Chris for your replies. I'll report back once
> > I've tried implementing (2).
>
> The pombe annotation extensions are now loaded, using plan (2). The
> results are here if anyone is interested:
> http://sloth.sysbiol.cam.ac.uk/~kmr44/dumps/current.dump.gz
>
> Thanks for you help.
>
> Kim.
>
> ------------------------------------------------------------------------------
> BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
> The must-attend event for mobile developers. Connect with experts.
> Get tools for creating Super Apps. See the latest technologies.
> Sessions, hands-on labs, demos & much more. Register early & save!
> http://p.sf.net/sfu/rim-blackberry-1
> _______________________________________________
> Gmod-schema mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gmod-schema