QuickGO setup (fwd)

[Kuan Chang]

---------- Forwarded message ----------
Date: Fri, 07 Sep 2001 10:18:31 +0100
From: Tom Oinn <tmo at ebi.ac.uk>
To: Kuan Chang <changku at cshl.edu>
Cc: wfl at ebi.ac.uk, alex at ebi.ac.uk
Subject: Re: QuickGO setup



Kuan Chang wrote:
> 
> Dear Mr. Oinn,
> 
> This is Kuan Chang from Cold Spring Harbor Laboratory.
> 
> We are planning to set up a QuickGO system locally.  Could you please let
> us know how to do it?   Also could you please send us a copy of your
> oracle database schema and some sample inputs to set up our local GO
> database?  Thank you very much!

Right. First - do you have a really good reason to have a local copy of
QuickGO? I ask because setting up the system will involve re-writing
parts of the code (potentially), not to mention installing several
complex databases to obtain the full functionality. Specifically, you
would need to install oracle versions of GO, InterPro and various
protein tables which both systems rely upon, combined with the fact that
both these data sets are updated daily. If you had achieved this, then
plugging QuickGO in would simply involve setting the database URL to
point to your install, but are you sure you want to do this?

The major problem with installing a modified QuickGO is that you would
loose the ability to track the latest version. Currently there are
several new features each week; it would be close to a full time job to
maintain the code and data to keep an up to date mirror.

In conclusion; if you're going to expose this as a public service then
I'd have to know that you have the resources allocated to track the
current versions of the code and data, this implies daily data updates
and weekly code updates. Of course, if it's for internal use only then
this is less critical, but for obvious reasons I'd prefer any public
versions of QuickGO to be at least reasonably up to date.

I have CC'd this mail to Wolfgang Fleischmann and Alexander Kanapin,
between the three of us we cover everything involved with
InterPro/QuickGO and the underlying tables, so they should be able to
supply more information on the database setup (I mainly work on the
software side).

Yours,

Tom Oinn