[Fwd: [Biojava-l] status? Blast parser?] Ooops!

Simon Brocklehurst simon.brocklehurst@CambridgeAntibody.com
Wed, 16 Feb 2000 18:43:11 +0000


This is a multi-part message in MIME format.
--------------3BB8347D3525F533CA8E980B
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

This time forwarding Terry's message (that's what happens when you've
had a "meeting" involving consumption of multiple bottles of wine!)

--
Simon M. Brocklehurst, Ph.D.
Head of Bioinformatics
Cambridge Antibody Technology
The Science Park, Melbourn, Cambridgeshire, UK
http://www.CambridgeAntibody.com/
mailto:simon.brocklehurst@CambridgeAntibody.com


--------------3BB8347D3525F533CA8E980B
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Return-Path: <Terry.Triplett@wl.com>
Received: from [192.168.1.2] (HELO camb-antibody)
  by camb-antibody.co.uk (CommuniGate Pro SMTP 3.1)
  with SMTP id 1265650 for simon.brocklehurst@CambridgeAntibody.com; Wed, 16 Feb 2000 16:20:00 +0000
Received: from defcon.aa.wl.com ([162.48.254.3]) by camb-antibody.camb-antibody.co.uk; Wed, 16 Feb 2000 16:39:55 +0000 (GMT)
Received: from toto.research.aa.wl.com by [162.48.254.3]
          via smtpd (for mailhost.camb-antibody.co.uk [193.129.118.107]) with SMTP; 16 Feb 2000 16:41:15 UT
Received: by toto.research.aa.wl.com with Internet Mail Service (5.5.2448.0)
	id <1XVFJTVZ>; Wed, 16 Feb 2000 11:40:53 -0500
Message-ID: <7CE841760399D111B18D00805F57336B05312345@coyote.research.aa.wl.com>
From: "Triplett, Terry" <Terry.Triplett@wl.com>
To: 'Simon Brocklehurst' <simon.brocklehurst@CambridgeAntibody.com>
Subject: RE: [Biojava-l] status?  Blast parser?
Date: Wed, 16 Feb 2000 11:40:04 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
	charset="iso-8859-1"
X-Mozilla-Status2: 00000000



> It's not hard to add SAX functionality to our systems, and if 
> the consensus view
> of people on the list is that we should go ahead and use 
> CAT's code as the basis
> for the biojava BLAST parser, we will definitely implement 
> that fairly quickly.
> If we get to that point, we'll need to agree on some standard 
> meta data
> conventions and I'll post a proposal (e.g. we are keen for 
> this software to work
> with software that has generic BLAST-like output (e.g. HMMER) 
> with the minimum
> of effort, so our proposal would probably reflect that).

Sounds wonderful.

I forwarded a copy of your earlier message to Wayne Parrott as well, just in
case he's interested in any of this.  The Blast-XML package looks
interesting ...
 
> With respect to your comment "with some control over 
> format/layout", can you be
> more specific as to what you mean by that?

Ah, you called my bluff!  

I wasn't thinking of anything too complicated, actually.  I'm working on a
Web application in which HTML output from a Blast parser would be part of a
larger page containing other data, navigation info, links, look-n-feel etc.
The body of the document (ie. HTML blast output) is nested within several
outer tables that help with layout and positioning.  

Within this context, some desirable areas over which to exert control would
be:

	- get the output as a table only, not a standalone html document.
	- simple formatting such as table width, cell spacing, cell padding,

	  alignment, borders on/off and so forth.  Basically the ability to
set
	  arguments to the <table> tag.
	- some rudimentary control over font size and color, just so the
table
	  doesn't clash too badly with the look of the rest of the page.
	- maybe some simple control over the content of the output.  Course
settings
	  like 'terse', 'verbose', 'summary' or the ability to selectively 
	  include/exclude certain columns in a table would be interesting,
but not
        essential.

Finer control than this would probably be asking too much for a general
BLAST parser object.  On the other hand, since this is java, reading
settings from a properties file into a Properties object and passing that to
the BLAST parser before rendering the table might be the way to go.  This
would actually allow pretty fine control over the table w/o much more work -
just defining a decent minimal set of properties and reasonable defaults
that could be overridden would do the job.  

I'd like to be able to include hyperlinks back to the original datasources
in the table, but at that level I'm thinking the easiest way to do that
would be to pull out the raw data and build the table myself.  

Long term the best thing might be to move the rendering logic into a
separate set of classes that can be as simple or sophisticated as needed.

Hope this helps,

Terry L. Triplett
Bioinformatics System Engineer
Parke-Davis


> Simon
> --
> Simon M. Brocklehurst, Ph.D.
> Head of Bioinformatics
> Cambridge Antibody Technology
> The Science Park, Melbourn, Cambridgeshire, UK
> http://www.CambridgeAntibody.com/
> mailto:simon.brocklehurst@CambridgeAntibody.com
> 
> 

--------------3BB8347D3525F533CA8E980B--