view release on metacpan or  search on metacpan

docs/GFF_Spec.html  view on Meta::CPAN

any and all [group] field tag-value pairs). 
<P>
This allows extra method-specific information to be transferred with the line.  However,
we discourage overuse of this feature: better to find a way to do it
with more true feature lines, and perhaps groups. (<b>Version 2
change</b>: we gave in and defined a structured way of passing
additional information, as described above under [group].  But the
sentiment of this paragraph still applies - don't overuse the
tag-value syntax. The use of tag-value pairs (with whitespace) renders problematic the parsing of
Version 1 style comments (following the group field, without a '#' character), so in Version 2,
such [group] trailing comments <B>must</B> start with the "#", as noted above.

<A NAME="meta_info"><h4> ## comment lines for meta information </h4>

There is a set of standardised (i.e. parsable) ## line types that can
be used optionally at the top of a gff file.  The philosophy is a
little like the special set of %% lines at the top of postscript
files, used for example to give the BoundingBox for EPS files.<P>

Current proposed ## lines are:

<dl>

  <dt><pre> ##gff-version 1 </pre>
  <dd> GFF version - in case it is a real success and we want to
change it.  The current version is 2. (<b>Version 2 change</b>!)

  <dt><pre> ##source-version {source} {version text} </pre>
  <dd> So that people can record what version of a program or package was
used to make the data in this file. I suggest the version is text
 without whitespace.  That allows things like 1.3, 4a etc.

  <dt> <pre> ##date {date} </pre>
  <dd> The date the file was made, or perhaps that the prediction
programs were run.  We suggest to use astronomical format: 1997-11-08
for 8th November 1997, first because these sort properly, and second
to avoid any US/European bias.

<dt> <pre> 
 ##DNA {seqname}
 ##acggctcggattggcgctggatgatagatcagacgac
 ##...
 ##end-DNA
</pre>

<dd> To give a DNA sequence.  Several people have pointed out that it may
be convenient to include the sequence in the file.  It should not
become mandatory to do so.  Often the seqname will be a well-known
identifier, and the sequence can easily be retrieved from a
database, or an accompanying file.

<dt> <pre> ##sequence-region {seqname} {start} {end} </pre>
<dd> To indicate that this file only contains entries for the
specified subregion of a sequence.

</dl>

Please feel free to propose new ## lines.

The ## line proposal came out of some discussions including Anders
Krogh, David Haussler, people at the Newton Institute on 1997-10-29
and some email from Suzanna Lewis.  Of course, naive programs can
ignore all of these...

<A NAME="file_names"><h3> File Naming </h3>

We propose that the format is called "GFF", with conventional file
name ending ".gff".
<P>
Back to <A HREF="#TOC">Table of Contents</A>
<P>
<HR>
<A NAME="semantics"><h2> Semantics </h2>

We have intentionally avoided overspecifying the semantics of the
format.  For example, we have not restricted the items expressible in
GFF to a specified set of feature types (splice sites, exons etc.)
with defined semantics.  Therefore, in order for the information in a
gff file to be useful to somebody else, the person producing the
features must describe the meaning of the features.  <P>

In the example given above the feature "splice5" indicates that there
is a candidate 5' splice site between positions 172 and 173.  The
"sp5-20" feature is a prediction based on a window of 20 bp for the
same splice site.  To use either of these, you must know the position
within the feature of the predicted splice site.  This only needs to
be given once, possibly in comments at the head of the file, or in a
separate document.  <P>

Another example is the scoring scheme; we ourselves would like the
score to be a log-odds likelihood score in bits to a defined null
model, but that is not required, because different methods take
different approaches.

Avoiding a prespecified feature set also leaves open the possibility
for GFF to be used for new feature types, such as CpG islands,
hypersensitive sites, promoter/enhancer elements, etc.
<P>
Back to <A HREF="#TOC">Table of Contents</A>
<P>
<HR>
<A NAME="GFF_use"><h2> Ways to use GFF </h2>

Here are a few suggestions on how the GFF format might be used.
 <ol>
 <li> Simple sharing of sensors. In this case, researcher A has a sensor,
such as a 3' splice site sensor, and researcher B wants to test that
sensor.  They agree on a set of sequences, researcher A runs the
sensor on these sequences and sends the resulting GFF file to
researher B, who then evaluates the result.<P>

 <li> Representing experimental results.  GFF feature records can also
be created for experimentally confirmed exons and other features.  In
these cases there will presumably be no score.  Such "confirmed" GFF
files will be useful for evaluating predictions, using the same
software as you would to compare predictions.<P>

 <li> Integrated gene parsing. Several GFF files from different
researchers can be combined to provide the features used by an
integrated genefinder.  As mentioned above, this has the advantage
that different combinations of sensors and dynamic programming methods

docs/GFF_Spec.html  view on Meta::CPAN

<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>