Gene ontology obo files

Chris Mungall Amelia Ireland. OBO format is the text file format used by OBO-Edit , the open source, platform-independent application for viewing and editing ontologies. The formal specification is normative, this document is only a guide. This document supersedes the obsolete 1. Syntactic changes are minimal. Any changes between OBO-Format 1. See further on in this document for a summary of these changes. The format is similar to the tag-value format of the GO definitions file, with a few modifications.

One important difference is that unrecognized tags in any context do not necessarily generate fatal errors although some parsers may decide to do so; see Parser Requirements below.

This allows parsers to read files that contain information not used by a particular tool. The header is an unlabeled section at the beginning of the document containing tag-value pairs. The header ends when the first stanza is encountered. A stanza is a labeled section of the document, indicating that an object of a particular type is being described.

Stanzas consist of a stanza name in square brackets, and a series of tag-value pairs , structured as follows:. An OBO file may contain any number of lines beginning with!

These lines are ignored by parsers. Further, any line may end with a! Parsers that encounter an unescaped! The tag name is always a string. The value is always a string, but the value string may require special parsing depending on the tag with which it is associated.

In general, tag-value pairs occur on a single line. Multi-line values are possible using escape characters see escape characters. In general, each stanza type expects a particular set of pre-defined tags.

However, a stanza may contain any tag. If a parser does not recognize a tag name for a particular stanza, no error will be generated.

This allows new experimental tags to be added without breaking existing parsers. See handling unrecognized tags for specifics. Any tag-value pair may be followed by a trailing modifier. Trailing modifiers have been introduced into the OBO 1. However, this is not required.

A parser may choose to ignore or strip away trailing modifiers. For this reason, trailing modifiers should only include information that is optional or experimental. Trailing modifiers may also occur within dbxref definitions see dbxref formatting. Escaped characters should only be used when a literal character is needed that is, a character that the parser should not interpret as having a special meaning when parsing.

Some tag values may contain unescaped colons, brackets, quotes, etc. Unescaped spaces between the separator colon and the start of the value tag are discarded. OBO parser implementations may support only these escape characters, or they may assume that any character following a backslash is an escaped character. The ID should not contain any whitespace.

The scope specifier indicates the default scope for any synonym that has this type. See the synonym section of tags in a term stanza for more information on the scope specifier. Cardinality: any. The above will make sure that all relations referred to in the current file come from the OBO relations ontology, unless otherwise specified.

The scope of this tag is within the current file only. See also id-mapping , below. Note that the default-relationship-id-prefix tag takes precedence over this tag. Treats all xrefs coming from a particular ID-Space as being statements of exact equivalence. Normally, xrefs have no special meaning beyond "This xref is of relevance to the current entity". Treats all xrefs coming from a particular ID-Space as being genus-differentia definitions cross products, logical definitions, intersection definitions.

Treats all xrefs coming from a particular ID-Space as being relationships. By default, an obo namespace note: not ID-space partitions all the entities such that no two entities belonging to the same namespace may be equivalent. The GO subsets from to were deposited to give an easy access to the GO slim used in a particular publication or analysis and for reuse by the GO community at the time.

Some of these GO slims are no longer maintained by the authors and as such can contain obsoleted GO terms. Although we recommend to use the. If you are looking for current, actively maintained GO slims, please see the guide to GO subsets. In addition to the folder hierarchy described above, the GO DOI releases produced from March contain additional folders. Each of those systems was created at different times to serve different purposes and they were partially redundant, both in terms of the types of data they contained and in time frames e.

The project is hosted on GitHub. Please contact the GO Helpdesk if you have any questions. Toggle navigation. Citation How do I cite an ontology?

Terms How do I request a new ontology term? Contribute How do I submit my ontology? How do I request a review of my ontology? Where can I find ontology reviews? Ontology display How do I edit the metadata for my ontology?