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

[Chris M. <cjm...@lb...>]

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
>> go-...@li...
>> https://mailman.stanford.edu/mailman/listinfo/go-discuss
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Gmod-devel mailing list
> Gmo...@li...
> https://lists.sourceforge.net/lists/listinfo/gmod-devel