Quantcast

GAFs, GPADs, LEGO and GMOD

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

GAFs, GPADs, LEGO and GMOD

Chris Mungall-5
Dear GMODders,

Following on from a recent discussion on gmod-schema involving Eric and
Siddhartha, I thought this would be a good opportunity to clarify some
differences between some existing GO association formats, and to give
you a heads-up about a new more expressive way of doing GO annotation
you'll be seeing soon.

I posted some details here:
http://geneontology.org/article/gaf-gpad-and-lego

In particular, I wanted to draw your attention to the more expressive
form of LEGO annotations. The best way to grok this is by having a look
at some existing annotations and documentation here:
http://noctua.berkeleybop.org/

Although I think it's too early to start thinking about integrating this
into the GMOD stack, we can still have a conversation about how this
might work. For example, WormBase are exploring the addition of a Noctua
widget into their pages. What we learn from this could feed into generic
GMOD tools like Tripal - it would be great to see LEGO diagrams in
there.

I'd be happy to answer any questions over on the GMOD lists. Also, if
any of you are at ISB/Biocuration then there will be many GO experts
there, as well as the Noctua developer, Seth. Paul Thomas will be giving
a talk about the modeling paradigm. Feel free to ask us questions!

Cheers,
Chris

------------------------------------------------------------------------------
_______________________________________________
Gmod-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [go-discuss] GAFs, GPADs, LEGO and GMOD

Siddhartha Basu
Hi Chris,
I have a quick look and using owl for modeling GO
annotations makes more sense. GO annotations now a days have linked
data(annotation extensions) and the flat file format is really getting
stretched. The implicit dependencies and connections in the flat file is just impossible
to express.
So, this is something i would like to revisit
in detail besides modeling GPAD into chado. For the time being just want
to brainstorm few ideas/questions that comes from the first look.
* Unless we go full owl for modeling annotations, we have to use owltools command to
  convert gpad into lego compatible owl.
* How do we store these owl model for querying it.
  Could we just shove it in a triple store like Jena TDB. Is there any
  other options.
* How do we query that model. Is sparql an option. Or there is an high
  level api.
* How does noctua fits here. It seems to have its own customized stack.
  Does it play well with other generic rdf/semantic/linked data tool.

thanks,
-sidd


On Tue, 05 Apr 2016, Chris Mungall wrote:

> Dear GMODders,
>
> Following on from a recent discussion on gmod-schema involving Eric
> and Siddhartha, I thought this would be a good opportunity to
> clarify some differences between some existing GO association
> formats, and to give you a heads-up about a new more expressive way
> of doing GO annotation you'll be seeing soon.
>
> I posted some details here:
> http://geneontology.org/article/gaf-gpad-and-lego
>
> In particular, I wanted to draw your attention to the more
> expressive form of LEGO annotations. The best way to grok this is by
> having a look at some existing annotations and documentation here:
> http://noctua.berkeleybop.org/
>
> Although I think it's too early to start thinking about integrating
> this into the GMOD stack, we can still have a conversation about how
> this might work. For example, WormBase are exploring the addition of
> a Noctua widget into their pages. What we learn from this could feed
> into generic GMOD tools like Tripal - it would be great to see LEGO
> diagrams in there.
>
> I'd be happy to answer any questions over on the GMOD lists. Also,
> if any of you are at ISB/Biocuration then there will be many GO
> experts there, as well as the Noctua developer, Seth. Paul Thomas
> will be giving a talk about the modeling paradigm. Feel free to ask
> us questions!
>
> Cheers,
> Chris
> _______________________________________________
> go-discuss mailing list
> [hidden email]
> https://mailman.stanford.edu/mailman/listinfo/go-discuss

------------------------------------------------------------------------------
_______________________________________________
Gmod-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [go-discuss] GAFs, GPADs, LEGO and GMOD

Chris Mungall-5


On 7 Apr 2016, at 9:30, Siddhartha Basu wrote:

> Hi Chris,
> I have a quick look and using owl for modeling GO
> annotations makes more sense. GO annotations now a days have linked
> data(annotation extensions) and the flat file format is really getting
> stretched. The implicit dependencies and connections in the flat file
> is just impossible
> to express.

Exactly

> So, this is something i would like to revisit
> in detail besides modeling GPAD into chado. For the time being just
> want
> to brainstorm few ideas/questions that comes from the first look.
> * Unless we go full owl for modeling annotations, we have to use
> owltools command to
>   convert gpad into lego compatible owl.

you mean (lossy) lego->gpad,gaf?

Yes, you can use our converter to do that --- but you won't have to. The
GOC is committed to continued support for annotations in GAF/GPAD. You
should just be aware that this will not capture the richness of the lego
model. But we're not forcing anyone to do any extra work.

Note that for particular kinds of bioinformatics application, other
kinds of lossy transformation may be fine - e.g. getting files for use
in cytoscape.

I would say that GMOD ultimately has a broader picture though.

> * How do we store these owl model for querying it.
>   Could we just shove it in a triple store like Jena TDB. Is there any
>   other options.

There are a variety of options - LEGO fits naturally into a graph or RDF
store (as its native form is RDF/OWL). We are also storing the graph
blobs in a Solr index for fast access and querying via AmiGO. This isn't
intended to support rich queries involving pathway connections, but
rather for things like "which models have mouse genes with kinase
activity"

And you could use a relational store if you really wanted to. You don't
need to express all of OWL. You could design a datamodel around the
types we use in LEGO - functions, processes, components, molecular
entities, causal links. But we'd probably both be in agreement that it
would be more natural to use a graph-level abstraction.

The question for GMOD is do we want to consolidate everything into one
store, or have a federated approach, with different data types in
different kinds of store, optimized for that datatype? If things are
consolidated, is that via incremental extensions of existing schemas, or
through of a redesign, with (for example) a rdf/graph store front and
center?

There are multiple possibilities here. For example, a GMOD application
like Tripal could integrate the AmiGO LEGO widget, and have that
communicate with our service. Or we could explore the route of having a
tighter coupling.

> * How do we query that model. Is sparql an option. Or there is an high
>   level api.

Within GO, there will be a mixture of both. For retrieval purposes, we
have an unpublished very high level API for fetching entire models based
on what genes they contain etc, for this use case:
https://github.com/geneontology/noctua/issues/221

> * How does noctua fits here. It seems to have its own customized
> stack.
>   Does it play well with other generic rdf/semantic/linked data tool.

It's primarily an editing tool so it has its own custom stack for
handing distributed simultaneous editing of models. But the back-end
component is mostly a layer on top of OWL. So it depends exactly what
you mean, but one thing to note is that as the native form is rdf/owl,
so anything in the semweb stack will work on it out of the box.

Hope this answers some of your questions,
Chris

> thanks,
> -sidd
>
>
> On Tue, 05 Apr 2016, Chris Mungall wrote:
>
>> Dear GMODders,
>>
>> Following on from a recent discussion on gmod-schema involving Eric
>> and Siddhartha, I thought this would be a good opportunity to
>> clarify some differences between some existing GO association
>> formats, and to give you a heads-up about a new more expressive way
>> of doing GO annotation you'll be seeing soon.
>>
>> I posted some details here:
>> http://geneontology.org/article/gaf-gpad-and-lego
>>
>> In particular, I wanted to draw your attention to the more
>> expressive form of LEGO annotations. The best way to grok this is by
>> having a look at some existing annotations and documentation here:
>> http://noctua.berkeleybop.org/
>>
>> Although I think it's too early to start thinking about integrating
>> this into the GMOD stack, we can still have a conversation about how
>> this might work. For example, WormBase are exploring the addition of
>> a Noctua widget into their pages. What we learn from this could feed
>> into generic GMOD tools like Tripal - it would be great to see LEGO
>> diagrams in there.
>>
>> I'd be happy to answer any questions over on the GMOD lists. Also,
>> if any of you are at ISB/Biocuration then there will be many GO
>> experts there, as well as the Noctua developer, Seth. Paul Thomas
>> will be giving a talk about the modeling paradigm. Feel free to ask
>> us questions!
>>
>> Cheers,
>> Chris
>> _______________________________________________
>> go-discuss mailing list
>> [hidden email]
>> https://mailman.stanford.edu/mailman/listinfo/go-discuss
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Gmod-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gmod-devel

------------------------------------------------------------------------------
_______________________________________________
Gmod-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-devel
Loading...