[DAS] "XGLT" XML based bioinformatics functional programming language(s) proposal

McCulloch, Alan alan.mcculloch at agresearch.co.nz
Mon Jun 2 16:56:25 EDT 2003


I'm posting this naive proposal for an XML based 
functional-programming style of bioinformatics language , 
or collection of languages, to the main open-bio lists 
I am familiar with to try  to find out if anybody else 
is interested in thinking about a non-naive proposal, 
or knows somebody who might be , or is already doing so.

For very tentative examples of the sort of
thing I have in mind, see Examples 1. and 2. below.

(For one overview of functional programming 
languages and XML see for example  
http://www.xml.com/pub/a/2001/02/14/functional.html)

In what follows  an XML based functional-programming 
style of bioinformatics language is referred 
to as an XGLT (i.e. XSLT-with-a-G, "Genetic 
Transformation  Language", for want of a better term, 
though its not really related to Genetics specifically, 
so the G is moot).

The main ideas initially are that such a language 
would 

   * provide a high-level implementation-independent 
   interface to the rich Object Oriented (O-O) libraries 
   (BioJava , BioPERL, BioPython and others), more accessible 
   to  non-experts, and to developers working in other
   environments. XGLT interpreters could 
   be developed using these libraries.

   * provide an alternative "constructive" way
   of representing biological sequence and other 
   data. An XGLT based data packet would in general 
   express how to (reconstruct) a given piece of 
   biological sequence data - e.g. a sequence, or 
   a consensus alignment of sequences ,or a 
   translation - rather than convey the data itself, 
   or any  particular model of the data. While 
   initially limited to sequence data , it is possible 
   such a  functional programming dual may find 
   application  to other biological data. 
  

Such languages would have the following benefits


1) They would enable reference to and exchange of 
   large complex data structures , such as alignments, 
   in a succinct form, and very suitable for further 
   manipulation.
   (Example 1 below)


2) Because such languages would in most cases 
   exchange statements about how to (re)construct 
   data , rather  than the data itself ,they would 
   convey valuable  information lost when only the 
   end results are  transmitted - as an example, 
   any indels made in a DNA sequence read as part of its 
   protein translation. (Example 2 below)

3) Such languages could potentially provide a convenient 
   higher-level more declarative style of functional 
   programming interface  to Object Oriented libraries , 
   such as BioJava, BioPerl, BioPython  and others, 
   as these O-O libraries could be used to write the XGLT 
   engines required to actually interpret and execute XGLT 
   statements.


4) A functional programming style lends itself more 
   readily to expressing a chain of processing steps , 
   i.e. a (mini-) pipeline, than does an Object 
   Oriented system , which is more  expressive of 
   static structure.See example 2 below for a 
   very simple/naive example of a micro-translation-pipeline 
   expressed as a nested series of transforms in an XGLT. 


5) This point is related to both point 3) and point 4)
   above.

   It is likely that one popular method of making 
   Bioinformatic software libraries such as the Bio* 
   projects accessible to the non-expert and/or 
   non-Java/Perl/Python user will be to build Web 
   Services directories (WSDL), with each service 
   mapping to  a static Bio* facade method, that 
   internally creates temporary Bio* Objects to 
   execute the service method.

   However this approach is really limited to 
   one-shot services. Where a task calls for a 
   series of services to be invoked in a pipeline, 
   the fact that the underlying Bio* objects do not 
   persist between calls  is a problem , which would 
   require expensive marshalling  of output and  input 
   between web-service calls.

   The combination of an XGLT language allowing a 
   non-expert  user to specify a nested series of 
   processing steps in a high-level 
   implementation-independent manner, with an XGLT 
   interpreter/engine written using one or more of 
   the well engineered rich O-O-based Bio* libraries, 
   would potentially allow the entire pipeline to be 
   executed within the O-O based engine, with objects 
   persisting as and when required, for the entire 
   pipeline process.
   
  
6) an advantage of making a functional-programming 
   representation XML based , is that in many cases the
   representation would not need to be interpreted by 
   a real XGLT interpreter to be useful.
 
   For example it is easy to use XSLT to 
   transform Example 1.  below , into something 
   like an SVG (http://www.w3.org/TR/SVG/) based display of 
   the patterns of variation in an alignment, without 
   even actually executing the various editing steps
   required to construct the reads.

   An XGLT dual of a protein reference sequence , as in
   Example ,. includes enough information to 
   plot a rich feature track on a genome viewer, without 
   actually executing the translation.
   


Finally ,it would be desirable to provide some sort of
theoretical context for the suggestions and examples 
presented here , and so I give a very tentative one.

Comparing the two representations of an alignment
of sequences in Example 1, both contain the same
information, but one (the XGLT version) is projected into 
a space of functions, and the other into a geometric space.

This is analogous to the duality betwen the time-domain 
and frequency domain representations of a mathematical
function or data series.

(Another analogy is with the duality between a vector
space and the dual-space of linear functionals defined
on that space)

Others have pointed out a duality relationship between 
Object Oriented and Functional Programming languages.

So the tentative theoretical context , is that 
expressions in XGLT languages would amount to almost 
formal duals of the original data and models.

Therefore I would suggest the XGLT representation of
something like an alignment (Example 1) or 
protein translation (Example 2) , be referred to as
the "XGLT dual" or "functional programming dual" of the 
original , to emphasize that we are really dealing with 
the same information , but projected into a 
different space - one of functions.

And just as working in the frequency domain can 
sometimes be a productive thing to do with a 
mathematical function or data series, so working in a 
dual functional-programming domain as suggested here may 
be productive for some purposes.

I'd be grateful for any feedback (however harsh !)
on my admittedly very naive proposal.

Cheers

Alan McCulloch



---------------------------------------------------------------------
Example 1
---------------------------------------------------------------------

Set out below is a possible XGLT dual of the 
following alignment fragment : 


>Contig1
CGATCGAGCGTG


read1   CGATCCGAGCGTG
read2    GATC-GAGCGTG
read3     GACC-AGGGTT
read4    GACC-GAGCGT
read5     ATC-GA
        -------------
        CGATC-GAGCGTG






<!--
   this is an XGLT functional-programming dual
   of an alignment of reads making up a contig. 
   Rather than literally presenting the contig, consensus 
   and alignments, it gives instructions for how to construct 
   the consensus given the contig, and then for constructing 
   each read from the consensus - i.e.working backwards. 
-->
<mydata
   xmlns:xglt="www.pretend.xglt.org/XGLT-version-1.html"      
   xmlns:xbiopath="www.pretend.xglt.org/xbiopath-version-1.html"
   xmlns:xseqedit="www.pretend.xglt.org/xseqedit-version-1.html"
   xmlns:xprotein="www.pretend.xglt.org/xprotein-version-1.html">
   <!--
      provide the contig starting point
   -->
   <contig1>
      CGATCGAGCGTG
   </contig1>

   <!--
      a transform to obtain the consensus
   -->
   <xglt:transform name="consensus">
      <xbiopath:copy_sequence source="../contig1"/>
      <xseqedit:insert from="5" value="gap()" count="1"/>
   </xglt:transform>

   <!--
      transforms to obtain each read from the 
      consensus- we only need to specify changes from the 
      consensus. Each transform first calls the above consensus 
      transform, to provide its starting point (an XGLT interpreter 
      engine would of course optimise such multiple calls away in 
      the actual 
      execution)
   -->
   <xglt:transform name="read1">
      <xglt:apply_transform name="../consensus"/>
      <xseqedit:substitute from="6" to="6" value="C"/>
   </xglt:transform>
   <xglt:transform name="read2">
      <xglt:apply_transform name="../consensus"/>
      <xseqedit:substitute from="1" to="1" value="null()"/>
   </xglt:transform>
   <xglt:transform name="read3">
      <xglt:apply_transform name="../consensus"/>
      <xseqedit:substitute from="1" to="2" value="null()"/>
      <xseqedit:substitute from="3" to="3" value="G"/>
      <xseqedit:substitute from="4" to="4" value="A"/>
      <xseqedit:substitute from="6" to="6" value="C"/>
      <xseqedit:substitute from="7" to="7" value="gap()"/>
      <xseqedit:substitute from="10" to="10" value="G"/>
      <xseqedit:substitute from="13" to="13" value="T"/>
   </xglt:transform>
   <xglt:transform name="read4">
      <xglt:apply_transform name="../consensus"/>
      <xseqedit:substitute from="1" to="1" value="null()"/>
      <xseqedit:substitute from="4" to="4" value="C"/>
      <xseqedit:substitute from="13" to="13" value="null()"/>
   </xglt:transform>
   <xglt:transform name="read5">
      <xglt:apply_transform name="../consensus"/>
      <xseqedit:substitute from="1" to="2" value="null()"/>
      <xseqedit:substitute from="9" to="13" value="null()"/>
   </xglt:transform>
</mydata>



------------------------------------------------------------------------
---------------
Example 2
------------------------------------------------------------------------
---------------
          
<!--
   this is an XGLT functional-programming dual
   of a hypothetical RefSeq protein sequence, that has 
   undergone a curated translation from an underlying read 
   (hg11 genome say) that contains errors. Rather than 
   presenting the literal end-product sequence, this dual gives 
   instructions for how to construct it. When processed by an XGLT 
   interpreter/engine, the end result would simply be the 
   RefSeq protein sequence
-->
<xglt:transform 
   name="myRefSeqProtein"
   xmlns:xglt="www.pretend.xglt.org/XGLT-version-1.html"      
   xmlns:xbiopath="www.pretend.xglt.org/xbiopath-version-1.html"
   xmlns:xseqedit="www.pretend.xglt.org/xseqedit-version-1.html"
   xmlns:xprotein="www.pretend.xglt.org/xprotein-version-1.html">

   <!-- 
      this transform retrieves 3 exons from hg11 and 
      concatenates them into a single string 
   -->
   <xglt:transform name="getMyRefseqExons">
      <xbiopath:extract_sequence target="hg11">
         <xbiopath:subseq start="chr3.12345" stop="chr3.12545"/>
         <xbiopath:subseq start="chr3.23456" stop="chr3.23656"/>
         <xbiopath:subseq start="chr3.34567" stop="chr3.34667"/>
         <xglt:concatenate xref="./workspace()"/>
      </xbiopath:extract_sequence>
   </xglt:transform>

   <!-- 
      this transform calls the above transform to retrieve
      sequence,and then applies some edits 
   -->
   <xglt:transform name="myCuratedRefSeq">
      <xglt:apply_transform name="../getMyRefseqExons"/>
      <xseqedit:delete from="100" to="110"/>
      <xseqedit:insert from="50" value="G" count="1"/>
      <xseqedit:substitute from="200" to="200" value="G"/>
   </xglt:transform>

  

   <!--
      this transform calls the above transform to supply a DNA
      sequence , and then translates it
   -->   
   <xglt:transform name="translation">
      <xglt:apply_transform name="../myCuratedRefSeq"/>
      <xprotein:translate species="human"/>
   </xglt:transform>
</xglt:transform>


------------------------------------------------------------------------
--------------
Comment on Above Examples
------------------------------------------------------------------------
-------------


In these examples I have...

1) ...tried to suggest a functional style of 
   programming, but an actual XGLT may look 
   quite different.
   Transformations are declared and referenced inside 
   other transformations, in a nested structure. Each 
   transform stands alone , in that it first calls 
   another transform that provides its starting point 
   (and this transform may in turn involve a call to 
   another transform, etc)

2) ...tried to demonstrate how an XGLT would convey 
   valuable information about (in this example) the way 
   the RefSeq was made, not just the sequence of the 
   RefSeq itself. We not only achieve a succinct and in 
   this case compressed expression of the actual sequence 
   of the RefSeq, we also have an audit-trail of how the 
   RefSeq was curated.

3) ...supposed that rather than a single xglt language/name-space, 
   there would be a collection of namespaces such as

xglt: basic language for expressing things in a 
   functional programming manner - defining and 
   referencing transforms etc.
                
xbiopath: functions for referencing and extracting 
   biological sequences from databases and genomes. The 
   example given in (1) is a simple coordinate based 
   extract , but one could also envisage specifying things 
   like similarity based paths....

<xbiopath:match_sequence query="../myCuratedRefSeq()" 
          method="blast -e 1.0e-30"
          target="hg15" offset=-2000 length=2500/>

   - this would result in the extraction of 2.5Kb 
   sections of sequence, from all positions 2Kb upstream 
   of any hg15 hits to the RefSeq that was constructed in 
   example 1.
       

xprotein: functions for working with protein primary and 
   secondary structure

xseqedit: basic functions for sequence editing. This 
   example shows indels and changes - one can also envisage
   , say, masking and quality trimming functions that 
   could be specified in a transform, as part 
   of a pipeline.


4) noted that one would  also want to be able to use 
   XPath-ish (http://www.w3.org/TR/xpath) references, to 
   other parts of the current or other XGLT documents.

       
=======================================================================
Attention: The information contained in this message and/or attachments
from AgResearch Limited is intended only for the persons or entities
to which it is addressed and may contain confidential and/or privileged
material. Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by persons or
entities other than the intended recipients is prohibited by AgResearch
Limited. If you have received this message in error, please notify the
sender immediately.
=======================================================================



More information about the DAS mailing list