view release on metacpan or  search on metacpan

docs/GFF_Spec.html  view on Meta::CPAN

 | 
<A HREF=/Software/><B>Software</B></A>
 | 
<A HREF=/Teams/>Teams</A>
 | 
<A HREF=http://search.sanger.ac.uk>Search</A>
 | 
      </FONT></TT>
     </TD>
    </TR>
     <TR>      <TD ALIGN=LEFT VALIGN=TOP NOWRAP>
      <FONT FACE=Arial,Helvetica,sans-serif SIZE=-1><TT>
      <A HREF=/><IMG WIDTH=11 HEIGHT=10 BORDER=0 HSPACE=0 ALIGN=TOP ALT="Home page" SRC=/icons/arrow.small.up.gif> Home</A>

<A HREF=/Software/><IMG WIDTH=11 HEIGHT=10 BORDER=0 HSPACE=0 ALIGN=TOP ALT="up to Software & Databases " SRC=/icons/arrow.small.left.gif> Software & Databases </A>
<A HREF=/Software/GFF/><IMG WIDTH=11 HEIGHT=10 BORDER=0 HSPACE=0 ALIGN=TOP ALT="up to GFF" SRC=/icons/arrow.small.left.gif> GFF</A>
      </TT></FONT>
     </TD>
    </TR>
   </TABLE>

  </TD>
 </TR>
</TABLE>

<P>

<!-- open table cell holding the page content -->
<CENTER><TABLE BORDER="0" WIDTH="80%"><TR><TD ALIGN="LEFT" VALIGN="TOP">

<!-- page content starts here -->


<A NAME="TOC">
<H1 ALIGN="CENTER">GFF (Gene Finding Features) Specifications Document</H1>
<!-- INDEX BEGIN -->
<UL>
	<LI><A HREF="#introduction">Introduction</A>
	<LI><A HREF="#version_2_update">Version 2 GFF Update</A>
	<LI><A HREF="#fields">Definition</A>
        <UL>
	   <LI><A HREF="#standard_feature_table">Standard Table of Features</A>
           <LI><A HREF="#group_field">Group Field</A>
	   <LI><A HREF="#comments">Comments</A>
           <UL>
              <LI><A HREF="#meta_info">Comments for Meta-Information</A>
           </UL>
	   <LI><A HREF="#file_names">File Naming</A>
        </UL>
	<LI><A HREF="#semantics">Semantics</A>
	<LI><A HREF="#GFF_use">Ways to use GFF</A>
	<UL>
	   <LI><A HREF="#examples">Complex Examples</A>
	   <UL>
              <LI><A HREF="#homology_feature">Similarities to Other Sequences</A>
           </UL>
	   <LI><A HREF="#cum_score_array">Cumulative Score Arrays</A>
	</UL>
	<LI><A HREF="#mailing_list"> Mailing list</A>
	<LI><A HREF="#edit_history">Edit History</A>
	<LI><A HREF="#authors">Authors</A>
</UL>
<!-- INDEX END -->
<HR>
<A NAME="introduction"><h2>Introduction</h2></A>
<P>
Essentially all current approaches to gene finding in higher organisms
use a variety of recognition methods that give scores to likely
signals (starts, splice sites, stops etc.) or to extended regions
(exons, introns etc.), and then combine these to give complete gene
structures.  Normally the combination step is done in the same program
as the feature detection, often using dynamic programming methods.  We
would like to enable these processes to be decoupled, by proposing a
format called GFF (Gene-Finding Format) for the transfer of feature
information.  It would then be possible to take features from an
outside source and add them in to an existing program, or in the
extreme to write a dynamic programming system which only took external
features.
<P>

In particular, establishing GFF would allow people to develop features
and have them tested without having to maintain a complete
gene-finding system.  Equally, it would help those developing and
applying integrated gene-finding programs to test new feature
detectors developed by others, or even by themselves.
<P>

We want the GFF format to be easy to parse and process by a variety of
programs in different languages.  e.g. it would be useful if Unix
tools like grep, sort and simple perl and awk scripts could easily
extract information out of the file.  For these reasons, for the
primary format, we propose a record-based structure, where each
feature is described on a single line, and line order is not relevant.
<P>

We do not intend GFF format to be used for complete data management of
the analysis and annotation of genomic sequence.  Systems such as
Acedb, Genotator etc. that have much richer data representation
semantics have been designed for that purpose.  The disadvantages in
using their formats for data exchange (or other richer formats such as
ASN.1) are (1) they require more complexity in parsing/processing, (2)
there is little hope on achieving consensus on how to capture all
information.  GFF is intentionally aiming for a low common
denominator. <P>

Here are some example records:

<pre>
SEQ1	EMBL	atg	103	105	.	+	0
SEQ1	EMBL	exon	103	172	.	+	0
SEQ1	EMBL	splice5	172	173	.	+	.
SEQ1	netgene	splice5	172	173	0.94	+	.
SEQ1	genie	sp5-20	163	182	2.3	+	.
SEQ1	genie	sp5-10	168	177	2.1	+	.
SEQ2	grail	ATG	17	19	2.1	-	0
</pre>
<P>
Back to <A HREF="#TOC">Table of Contents</A>
<P>
<HR>
<A NAME="version_2_update"><h2>Version 2 GFF Update</h2></A>

docs/GFF_Spec.html  view on Meta::CPAN

mail to <A HREF="mailto:Majordomo@sanger.ac.uk">Majordomo@sanger.ac.uk</A> with the 
following command in the body of your email message:
<P>

<code>
    subscribe gff-list
</code>
<P>
<P>
Back to <A HREF="#TOC">Table of Contents</A>
<P>
<HR>
<A NAME="edit_history"><h2>Edit History</h2></A>
<P>
971028 rd: I changed the comment initiator to '#' from '//' because a 
single symbol is easier for simple parsers.<P>

971028 rd: We also now allow extra text after &#060;group&#062;
without a comment character, because this immediately proved useful.<P>

971028 rd: I considered switching from start-end notation to
start-length notation, on the suggestion of Anders Krogh.  This seems
nicer in many cases, but is a debatable point.  I then switched back!<P>

971028 rd: I added the section about name space.<P>

971108 rd: added ## line proposals - moved them into main text 971113.<P>

971113 rd: added extra "source" field as discussed at Newton Institute
meeting 971029.  There are two main reasons.  First, to help prevent
name space clashes -- each program would have their own source
designation.  Second, to help reuse feature names, so one could have
"exon" for exon predictions from each prediction program.<P>

971113 rd: added section on mailing list.<P>

980909 ihh: fixed some small things and put this page on the Sanger
GFF site.<P>

981216 rd: introduced version 2 changes.<P>

990226 rbsk: incorporated amendments to the version 2 specification as follows:<P>
<UL>
     <LI>Non-printing characters (e.g. newlines, tabs) in Version 2 double quoted
"free text values" must be explicitly represented by their C (UNIX) style 
backslash escaped character (i.e. '\t' for tabs, '\n' for newlines, etc.)<br>
     <LI>Removed field (256) and line (32K) character size limitations for Version 2.
     <LI>Removed arbitrary whitespace field delimiter permission from specification.
TAB ('\t') field delimiters now enforced again, as in Version 1.<br>
</UL>
990317 rbsk:
<UL>
   <LI>End of line comments following Version 2 [group] field tag-value structures must be 
       tab '\t' or hash '#' delimited.
</UL>       
<P>
<P>
Back to <A HREF="#TOC">Table of Contents</A>
<P>
<HR>
<A NAME="authors"><h2>Authors</h2></A>
<P>
GFF Protocol Specification initially proposed by: 
<A HREF="mailto:rd@sanger.ac.uk">Richard Durbin</a> and 
<A HREF="mailto:haussler@cse.ucsc.edu">David Haussler</a>
<P>with amendments proposed by: 
<A HREF="mailto:lstein@cshl.org">Lincoln Stein</a>, Anders Krogh and others.
<P>The GFF specification now maintained at the Sanger Centre by 
<A HREF="mailto:rbsk@sanger.ac.uk">Richard Bruskiewich</a>
<P>
Back to <A HREF="#TOC">Table of Contents</A>
<P>

<!-- page content ends here -->

</TD></TR></TABLE></CENTER>  <!-- close table for page content -->

 <HR ALIGN="CENTER" WIDTH="90%">

<!-- open table for page footer -->
<TABLE BORDER="0" WIDTH="100%">
 <TR>
  <TD ALIGN=LEFT>
   <I>
   last modified : 25-Mar-1999, 01:59 PM
   </I>
  </TD>

  <TD ALIGN=RIGHT>
   <A HREF=/Users/rbsk/>Richard Bruskiewich</A>
   <I>(<A HREF=mailto:rbsk@sanger.ac.uk>rbsk@sanger.ac.uk</A>)</I>
  </TD>
 </TR>
</TABLE>  <!-- close table for page footer -->

</BODY>
</HTML>