Also known as GFF3
file format for genomic data
GFF is a standard file format for storing genomic features in a text file. GFF stands for Generic Feature Format . GFF files are plain text, 9 column, tab-delimited files. GFF databases also exist. They use a schema custom built to represent GFF data. GFF is frequently used in GMOD for data exchange and representation of genomic data. GFF has several versions, the most recent of which is GFF3 . GFF3 addresses several shortcomings in its predecessor, GFF2 . GFF3 is the preferred format in GMOD , but data is not always available in GFF3 format, so you may have to use GFF2. The two versions are similar but are not compatible and scripts usually only work with one of the other format. This page discusses GFF3 in detail. GFF2 details are covered on a separate page . Unfortunately, people, documentation, and even this web site are not always clear about what version of GFF is being discussed. This web page will always specify which version it is referring to. The formal specification of GFF3 is on the Sequence Ontology web site. It completely describes the format, including column definitions, metadata and directives. It also contains lengthy sections explaining how to represent different situations in GFF3, including: Some of these cases are covered on this page as well. If you want the full and definitive explanation of GFF3 then see the standard . This first describes the format of the annotation section, and then provides explanations of how to represent several different types of data. The ID of the landmark used to establish the coordinate system for the current feature. IDs may contain any characters, but must escape any characters not in the set [a-zA-Z0-9.:^ $@!+ ?- ]. In particular, IDs may not contain unescaped whitespace and must not begin with an unescaped “ ”. For zero-length features, such as insertion sites, start equals end and the implied site is to the right of the indicated base in the direction of the landmark. These fields are required. The strand of the feature. + for positive strand (relative to the landmark), - for minus strand, and . for features that are not stranded. In addition, ? can be used for features whose strandedness is relevant, but unknown. For forward strand features, phase is counted from the start field. For reverse strand features, phase is counted from the end field. A list of feature attributes in the format tag=value. Multiple tag=value pairs are separated by semicolons. URL escaping rules are used for tags or values containing the following characters: “,=;”. Spaces are allowed in this field, but tabs must be replaced with the %09 URL escape. This field is not required. ID Indicates the unique identifier of the feature. IDs must be unique within the scope of the GFF file. Name Display name for the feature. This is the name to be displayed to the user. Unlike IDs, there is no requirement that the Name be unique within the file. Alias A secondary name for the feature. It is suggested that this tag be used whenever a secondary identifier for the feature is needed, such as locus names and accession numbers. Unlike ID, there is no requirement that Alias be unique within the file. Parent Indicates the parent of the feature. A parent ID can be used to group exons into transcripts, transcripts into genes, and so forth. A feature may have multiple parents. Parent can only be used to indicate a partof relationship. Gap The alignment of the feature to the target if the two are not collinear (e.g. contain gaps). The alignment format is taken from the CIGAR format described in the Exonerate documentation. ). See the GFF3 specification for more information. Derives from Used to disambiguate the relationship between one feature and another when the relationship is a temporal one rather than a purely structural “part of” one. This is needed for polycistronic genes. See the GFF3 specification for more information. Dbxref A database cross reference. See the GFF3 specification for more inf
Excerpt from a page describing this subject · 26,897 chars · not written by Vinony
via Wikidata · CC0
Discovered by embedding cosine similarity (sentence-transformers MiniLM, 384-dim).