BIOINFORMATICS SOFTWARE RESOURCE

1
BIOINFORMATICS SOFTWARE RESOURCE
T. N.Bhat
2
IMPACT OF ARCHIVAL OF SOFTWARE

• For depositors
• Contribution gets date stamped
• Ensures permanent recognition
• For users
• Guarantees simpler centralized access
• For historians
• Maintains information in its original form

3
WHY DO WE NEED BISR?

• At present
• Most (all!) archival efforts are limited to
  data
  
• Software resources are fragmented and they often
  come and go
  
• Software is frequently replaced without an
  established mechanism to obtain older versions
  for validation or verification purposes
  
• Lack of standards, uniformity and
  interoperability among software
  

4
Why not just use a web search engine?

• Searching the web is a lot more difficult and
  problematic than it seems to be. Example
  
• Drug Design Software 200,484 hits on Alta
  Vista
  
• Crystallography Software 411,770 hits on Alta
  Vista
  
• meaning a great deal of time can be spent trying
  to find the right tool.

5
BISR, helping to build the infrastructure

• Establish a database for bioinformatics software
• Provide links to sites which distribute software
• Provide a stable support for archiving and
  distributing software
  
• Develop and support application program
  interface
  
• Advocate and foster uniform data exchange formats
  and application program interfaces

6
Contacting the BISR

• The web address is
• http//bioinfo.nist.gov/BISR
• To submit links to software for inclusion email
  the web address to bisr_at_nist.gov

7
BISR first level tree search
8
BISR third level tree search
9
BISR- search results
10
Application Program Interface

• Components of a application software are
• Formats files (Fs)
• Standards definitions (SD)
• Application program (AP)
• User input (APUI)
• At present AP deals with all the above four
  aspects
  
• Proposal is to shift such responsibility to API

AP
SD
APUI
API
Fs
11
How API works?
Application program AP
Application program interfa
ce (API)

Application user APUI
DATA
mmCIF
PDB
XML
NMR STAR
12
API architecture

• API has three basic modules
• An application program module
• A request translator
• A file handler

13
Application program module

• This is the highest level of module through which
  an application program requests and receives
  data
  
• A user requests data using sql type selection
  statements
  
• By default all the data are returned as arrays of
  the form
  
• On demand data may also be returned in other
  formats like PDB or xml
  
• A user defines environmental variables like file
  name, file type and needed data using set and
  select statements
  

14
Request translator module

• This module translates and maps all user
  requests to a common frame
  
• A user request may come in several stages and the
  translator module coordinates all such requests
  
• Allows concatenation of multiple requests
• Provides basic functions like selection of
  main-chain atoms,transformation from orthogonal
  to crystal coordinates, rms, alignments
  

15
File handler module

• This module reads the actual data file or
  database to accumulate data
  
• A separate file handler is envisaged for each of
  the supported formats like XML or PDB or NMRSTAR
  
  
• File handler manages data dictionary and
  conventions as well

16
APUI query syntax

• A user program or a user may communicate with the
  API by using a subset of SQL commands of the
  following type
  
• Set file a myfile
• Set file_type a pdb
• Set file b legacy_data
• Set file_type b xml
• Set file c oracle_database
• Alias column_name x coordinate_x in file c
• Select x, y,z from a, b, c where residue name
  ala

17
ACKNOWLEDGEMENTS

• BISR team
• T. N. Bhat
• Michael Tung
• Phoebe Fagan
• Gary Gilliland
• Other contributors
• Paul A. Reneke
• Richard Morris
• Institutional collaborators
• CCPN, Cambridge, UK