[Genquire-dev] Re: [Bioperl-l] Genquire (fwd)

David Block dblock@gnf.org
Mon, 5 Nov 2001 09:29:51 -0800 (PST)


---------- Forwarded message ----------
Date: Mon, 5 Nov 2001 09:00:37 -0800 (PST)
From: David Block <dblock@gnf.org>
To: Ewan Birney <birney@ebi.ac.uk>
Cc: Elia Stupka <elia@fugu-sg.org>, Bioperl <bioperl-l@bioperl.org>
Subject: Re: [Bioperl-l] Genquire

On Mon, 5 Nov 2001, Ewan Birney wrote:

> On Mon, 5 Nov 2001, Elia Stupka wrote:
> 
> > Great stuff! I've been thinking of using the GUI with bioperl-db for a
> > long time, never got around it. We will be installing it very soon over
> > here and evaluating it. Just wandering, is the db very different from
> > bioperl-db? I feel we should think about converging the two or if Genquire
> > is clearly better, chuck some of it away,etc. In short, we should make
> > sure users that come fresh to the bio group are pointed to only one place
> > for handling sequences with a database, let's think about it, what are
> > your views?
> 
> When I first looked at GenQuire I felt it could not support "interface
> level" database transfer/access - and, in addition, it bound the database
> to the object at a very tight granularity (each edit on the object
> triggers an update/insert into the database).
> 
Ewan - I took your criticism to heart and installed an adaptor layer.  
Theoretically, the adaptor layer makes Genquire data-source independent.

However, no other data sources have been coded.  I think bioperl-db is a 
logical choice!

Elia - download Genquire and take a look at the pod files in GQ/Server and 
GQ/Server/DB.  I tried to explain what the database schema looks like and 
what the adaptors do.  A lot of the database functionality is achieved by 
implementing GQ::Server::ContextI.  You think I haven't been learning from 
bioperl ;)

I also want to create a DAS adaptor layer.  The object model is almost 
exactly the same, so that's just a matter of doing it.

This should mean that we could view (in separate windows) annotations from 
a bioperl-db store, a Genquire 'native' schema, and a das source all at 
the same time.  It would be fairly easy to combine the read-only data 
sources as separate 'types' in a SeqCanvas window, with a single 
read/write source for annotations, or no writable db, if all you want to 
do is view.

> 
> Bioperl-db was written with a more "ensembl like" in-memory business
> object which collaborates with a database adaptor, and the database
> adaptor can ->store() any Bio::SeqI compliant object. I didn't see that
> sort of functionality in GenQuire when I looked.

As you will see if you look, we're getting closer to that.  Storing from 
an in-memory SeqI object hasn't been done, but loading in GFF worked at 
one time (no guarantees right now).  But Genquire is a gui, and it only
creates Bio::SeqI objects from data sources it knows about, so de novo 
bulk loading should probably go through bioperl-db.  Then we need the 
adaptor layer to move things into Genquire.


> 
> 
> I was also a little worried about the "chat" table in GenQuire, which
> seemed a little out-of-scope!
> 
Hey, it was fun, and someday it might be useful! :}

> 
> Mark and Dave may well have moved it on from there and provided a better
> all-over database. Elia - I'd trust your call on what the best way forward
> was: either
> 
>    (a) maintain bioperl-db and genquire separately for separate tasks (no
> shame in this). Off hand I'd guess
> 
>        bioperl-db = relational database equivalent of storing flat file
> EMBL/GenBank, but with much better querying, response time and data
> managements
> 
>        genquire = relational database for annotation/curation of DNA
> sequence
> 
Genquire = GUI for annotation/curation of DNA sequence after storage in 
bioperl-db or genquire schema.

>        (ensembl = relation database for automatic annotation and large
> scale pipelining)
> 
Go ahead - I don't want that one... ;)

> 
>   (b) Refactor one into the other: probably the only sensible thing is to
> move bioperl-db into GenQuire and Dave and Mark have too much
> code/investment into GenQuire to unpick and put on to a different backend.
> 
> 
We've worked hard to make that refactoring a possibility.  Mark wants to 
create a Genquire adaptor layer based on his Genbank parser, which I hope 
to see come to light soon.  If Genquire can do that, it quickly becomes an 
arbitrary tool for displaying sequence, and with write access, for 
annotation of sequence.

I have been moving (note the new email address), so I have to take a good 
look at Ewan's new Annotation object.  We'll probably want to incorporate 
that into Genquire, at least via bioperl-db.

A linux box should arrive for me today, so I can quit using this ...... 
Windows machine.  Then code should start flowing.

-Dave


> 
> 
> Just because they all use SQL backends doesn't mean they all do the same
> thing of course...
> 
> ewan
> > 
> > Elia
> > 
> _______________________________________________
> Bioperl-l mailing list
> Bioperl-l@bioperl.org
> http://bioperl.org/mailman/listinfo/bioperl-l
> 

_______________________________________________
Bioperl-l mailing list
Bioperl-l@bioperl.org
http://bioperl.org/mailman/listinfo/bioperl-l