Semantics
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.
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.
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.
Back to Table of Contents
Similarities to Other Sequences
A major source of information about a sequence comes from similarities
to other sequences. For example, BLAST hits to protein sequences help
identify potential coding regions. We can represent these as a set of
"homology gene features", grouping hits to the same target as follows:
seq1 BLASTX similarity 101 136 87.1 + 0 HBA_HUMAN
seq1 BLASTX similarity 107 133 72.4 + 0 HBB_HUMAN
seq1 BLASTX similarity 290 343 67.1 + 0 HBA_HUMAN
If further information is needed about where in the target protein
each match occurs, it can be given after the protein name, e.g.
as the start coordinate in the target.
Version 2 change: In version 2 this has been formalised using
the tag Target which expects to be followed by the name of the target,
followed (optionally) by start and end point in the target as
integers, as in
seq1 BLASTX similarity 101 235 87.1 + 0 Target "HBA_HUMAN" 11 55 ; E_value 0.0003
We need to finalise on a tag model for gapped alignments...
Back to Table of Contents
Cumulative Score Arrays
One issue that comes up with a record-based format such as the GFF
format is how to cope with large numbers of overlapping segments. For
example, in a long sequence, if one tries to include a separate record
giving the score of every candidate exon, where a candidate exon is
defined as a segment of the sequence that begins and ends at candidate
splice sites and consists of an open reading frame in between, then
one can have an infeasibly large number of records. The problem is
that there can be a huge number of highly overlapping exon
candidates.
Let us assume that the score of an exon can be decomposed into three
parts: the score of the 5' splice site, the score of the 3' splice
site, and the sum of the scores of all the codons in between. In such
a case it can be much more efficient to use the GFF format to report
separate scores for the splice site sensors and for the individual
codons in all three (or six, including reverse strand) frames, and let
the program that interprets this file assemble the exon scores. The
exon scores can be calculated efficiently by first creating three
arrays, each of which contains in its [i]th position a value A[i] that
is the partial sum of the codon scores in a particular frame for the
entire sequence from position 1 up to position i. Then for any
positions i < j, the sum of the scores of all codons from i to j can
be obtained as A[j] - A[i]. Using these arrays, along with the
candidate splice site scores, a very large number of scores for
overlapping exons are implicitly defined in a data structure that
takes only linear space with respect to the number of positions in the
sequence, and such that the score for each exon can be retrieved in
constant time.
When the GFF format is used to transmit scores that can be summed for
efficient retrieval as in the case of the codon scores above, we ask
that the provider of the scores indicate that these scores are
summable in this manner, and provide a recipe for calculating the
scores that are to be derived from these summable scores, such as the
exon scores described above. We place no limit on the complexity of
this recipe, nor do we provide a standard protocol for such assembly,
other than providing examples. It behooves the sensor score provider
to keep the recipe simple enough that others can easily implement it.
Back to Table of Contents
![[New]](/icons/new.gif){kind=icon}
Standard Table of Attribute Tag Identifiers
The semantics of tags in attribute field tag-values pairs has not yet been
completely formalized, however a useful constraint is that they be
equivalent, where appropriate, to DDBJ/EMBL/GenBank feature 'qualifiers'
of given features (see
EMBL feature descriptions).