QUASAR Tutorial - Configuration Tags

For alignment parser, there is indeed a common scheme for the configuration tags. In detail:

  <parser>
      <parserClass>information about the parser class in the Quasar package</parserClass>
      <alignmentFile>path of the alignment file</alignmentFile>
      <pdbFilesExtension>extension of the pdb files</pdbFilesExtension>
      <pdbFiles>directory where to find the pdb files</pdbFiles>
      <parse3DInformation>tells the system to parse PDB files</parse3DInformation>
      <parseCAAtomsOnly>tells the system to parse only CA atoms</parseCAAtomsOnly>
  </parser>
 

Most of the tags should be self-explaining. In the following we give examples for valid values of the tags:

• parserClass: Java class that extends the quasar.parser.alignment.QuasarParser abstract class. In the current implementation valid values are:
  • quasar.parser.alignment.AlignmentParserQuasarFormat
  • quasar.parser.alignment.BenchmarkAlignmentParserOne
• alignmentFile: Any alignment file that can be parsed by the selected parser class
• pdbFilesExtension: Extension of the pdb files. Can be pdb<, ent or empty if the extension is already annotated to the protein id in the alignment file.
• pdbFiles: Any directory where to find the template (and query) PDB files used in the alignment file. This may also point to the main directory of a ASTRAL like file system of subdirectories which is also tested by the parser class in order to identify the pdb files.
• parse3DInformation: flag, telling the system if 3D information (i.e. PDB files) should be parsed. Valid values are true and false.
• parseCAAtomsOnly: flag, telling the system if only CA atoms of the PDB files or all atoms should be parsed. Valid values are true and false.

Score conductors are responsible for combining several scoring schemes to obtain a final score for the sequence-structure alignment. To configure Quasar correctly the configuration file must include the following tags that are not conductor specific:

  <scoreConductor>
      <conductorClass>valid score conductor class (see below)</conductorClass>
      <conductorConfig>
          conductor specific configuration (see below)
      </conductorConfig>
  </scoreConductor>
 

Additionally to this general information required by Quasar, the system requires score conductor specific configuration information which would be in most cases information about the scoring schemes to be used alongside with their own configuration (see below). In the following we will present the configuration details for the two score conductors implemented in the system so far.

Weighted sum score conductor

The weighted sum conductor is implemented in the class quasar.scoring.conductors.WeightedSumConductor and can also be configured from the graphical user interface. It is used to combine scores in a weighted, linear fashion. Each scheme can be assigned a weight and each scheme can be normalized to return scores that rank between 0 and 1. The configuration information tells the conductor which scoring schemes should be included in the weighted sum, which weight should be assigned to them and if they should be normalized. Therefore within the tags of the general conductor configuration one may include one or more tags of the following form:

  <scoringScheme>
      <weight>Weight assigned to the scoring scheme</weight>
      <normalized>flag telling if score should be normalized</normalized>
      <schemeClass>valid scoring scheme class (see below)</schemeClass>
      <config>scoring scheme specific configuration (see below)</config>
  </scoringScheme>
 

Formula tree score conductor

So far it is not accessible from the graphical user interface. The formula tree conductor can be used to represent any formula that is a combination of scoring schemes with the mathematical +, -, * and /. Those formulas can be represented by a tree-like structure which is implemented in the class quasar.scoring.conductors.FormulaTreeConductor. The tree is represented by internal and external nodes, the internal nodes are mathematical operations, while the external nodes are represented by scoring schemes. The conductor specific configuration is therefore built by internal and external nodes. A node is defined as follows:

  <node>
      <type>Type of the node. As shown below can be internal and external</type>
      <content>content of the node depending on the type of the node</content>
  </node>
 

If the node type is internal the node tag content must contain the following information:

  <nodeClass>valid internal node class</nodeClass>
  <leftTree>recursive definition of left subtree: another node, either internal or external</leftTree>
  <rightTree>recursive definition of left subtree: another node, either internal or external</rightTree>
 

The tag nodeClass specifies the mathematical operation that combines the scores returned from the left and the right subtrees. At the moment the following values are allowed:

• quasar.scoring.conductors.tree.PlusInternalNode
• quasar.scoring.conductors.tree.MinusInternalNode
• quasar.scoring.conductors.tree.MultiplyInternalNode
• quasar.scoring.conductors.tree.DivideInternalNode

  <scoringScheme>
      <weight>Weight assigned to the scoring scheme</weight>
      <normalized>flag telling if score should be normalized</normalized>
      <schemeClass>valid scoring scheme class (see below)</schemeClass>
      <config>scoring scheme specific configuration (see below)</config>
  </scoringScheme>
 

An example of a valid configuration file structure for the FormulaTreeConductor can be found here.

As already stated, independent of the score conductor configuration for a scoring scheme, scoring schemes might require additional configuration information that can be passed to the scoring scheme via the content of the corresponding tag of the score conductor tag. In the following we will give details for all scoring schemes implemented in the system so far.

SOV scoring scheme

This scheme requires 2D information (i.e. secondary structure information) for query and template and returns the SOV score (Segment overlap score) of the two secondary structure strings. The scheme is implemented in the class quasar.scoring.schemes.SOVScoringScheme and is a reimplementation of the SOV score described by Zemla et al. in Proteins, 34:220-223 (1999). The scheme does not require any additional information.

Q3 scoring scheme

This scheme requires 2D information (i.e. secondary structure information) for query and template and returns the Q3 score of the two secondary structure strings. The scheme does not require any additional information.

Matrix file scoring scheme

This scheme can be used as a connection to any valid Quasar matrix file (example) and is implemented in the class quasar.scoring.schemes.FileMatrixScoringScheme. It requires additional configuration information to be present in the tag of the score conductor tag. In detail the following tags must be specified:

  <matrix>path pointing to the Quasar matrix file to be used</matrix>
  <openGap>real number, open gap penalty (should be negative)</openGap>
  <extendGap>real number, extend gap penalty (should be negative)</extendGap>
 

3D contact scoring scheme

This scheme requires 3D information of the template structure to be available and is implemented in the class quasar.scoring.schemes.Contact3DScoringScheme. It scores sequence-structure alignments by scoring the environment a target amino acid is put in with respect to the template structure. The pair potential of two amino acids in contact is read from a file in the standard Quasar matrix file format (see example). The following additional information is required:

  <matrixFile>3D Scoring Matrix File (*.mat format)</matrixFile>
  <distanceThreshold>
      distance threshold until which two amino acids are regarded to be in contact (float)
  </distanceThreshold>
  <localEnvironment>
      number of amino acids left and right of every residue that are ignored in the contac calculations
  </localEnvironment>
 

Benchmark scores are used as standard-of-truth benchmarking criteria for sequence-structure alignments. Well known examples are MaxSub, APDB and Touch (references see below). As all other entities within the Quasar system, benchmark scores are initialized and configured using an XML like configuration tag. If Quasar should run in Benchmark mode, the configuration file has to contain a tag called . Within this tag, one or more tags of the type may be defined as shown below.

  <benchmarkConfig>
      <benchmarkScore>
          <scoreClass>valid benchmark score class (see below)</scoreClass>
          <config>Score specific configuration information tags (see below)</config>
      </benchmarkScore>
      <benchmarkScore>
          <scoreClass>another valid benchmark score class (see below)</scoreClass>
          <config>Score specific configuration information tags (see below)</config>
      </benchmarkScore>
 
	    ...
 
  </benchmarkConfig>
 

The following scores are implemented in the current official release of the system. They are all accessible via the graphical user interface.

APDB score

The APDB score has been described in Bioinformatics, Vol. 19 Suppl. 1 2003 with the title APDB: a novel measure for benchmarking sequence alignment methods without reference alignments by Orla O'Sullivan et al. Quasar contains a reimplementation of the score available through the class quasar.benchmark.scores.APDBScore. The score does not require any additional configuration information.

Touch score

The Touch score is also used in the CAFASP evaluation and is available here. Quasar contains a reimplementation of the score which is available through quasar.benchmark.scores.TouchScore. This score does also not require any additional configuration information.

MaxSub

The MaxSub superimposition algorithm as defined in Bioinformatics, Number 9, Volume 16, September 2000, 776 - 785. MaxSub: an automated measure for the assessment of protein structure prediction quality by Daniel Fischer et al. is reimplemented in Java by the class quasar.benchmark.scores.MaxSub. The only difference in the algorithm is, that the superimposition method to superimpose the fragments in the algorithm is not the same as the one used by Fischer at al. but the Fortran QRTFit method is used (again a Java reimplementation). MaxSub requires the following additional configuration information within the tag of the tag.

  <RMSDQualityScore>
	   value may be <i>true</i> or <i>false</i>, tells if RMSD should be used as quality score or the quality score defined by MaxSub (modification of the Levitt-Gerstein score)
  </RMSDQualityScore>
  <printToStandardOutput>
	   value may be <i>true</i> or <i>false</i>, tells if results should be written to standard output
  </printToStandardOutput>
  <writeOutputFiles>
	   value may be <i>true</i> or <i>false</i>, if true, Rasmol scripts to visualize superimposition are written to <i>proteinID.pdb.super</i>
  </writeOutputFiles>
  <outputDirectory>
      directory where to write the Rasmol scripts
  </outputDirectory>
 

TMScore

The TMScore has been defined in Proteins, 57:702-710, 2004 by Zhang and Skolnick in Scoring Function for Automated Assessment of Protein Structure Template Quality. It is a variation of the Levitt-Gerstein score and takes all aligned residues into account (for details see original paper). The score has been reimplemented in Java and uses a different superimposition technique than described in the original paper. Therefore results might be slightly different. The TMScore requires the following additional configuration information within the tag of the tag.

  <printToStandardOutput>
	   value may be <i>true</i> or <i>false</i>, tells if results should be written to standard output
  </printToStandardOutput>
  <writeOutputFiles>
	   value may be <i>true</i> or <i>false</i>, if true, Rasmol scripts to visualize superimposition are written to <i>proteinID.pdb.super</i>
  </writeOutputFiles>
  <outputDirectory>
	   directory where to write the Rasmol scripts
  </outputDirectory>
 

An example for a complete and valid configuration file for the Quasar system can be found here. As already mentioned several times, the most convenient way to create configuration files is using the graphical user interface of Quasar. Those files can also be saved and may be explored using any text editor available.