A collection of ontology descriptions. A description of the contents, source, etc. of an ontology If a submitter maintains the primary copy of the ontology outside obo, they must provide an exact URL path to the file, which must conform to core_format. This is a pointer to the "live" ontology, which may be changing daily or hourly! To point at a stable release, see version_info, below. If the submitter maintains the copy inside OBO, then the path can be local to the main OBO root. If the submitter is uploading an ontology release, then this can be left blank, as it is not applicable (a path is assigned automatically) cbio will provide downloading in a variety of formats as part of its service see http://www.fruitfly.org/~cjm/obo-download for a prototype. we also want to give people the option of hosting their own download areas. for example, certain groups may wish to provide custom mappings to OWL (for example, there are a number of different ways of mapping the FMA to OWL and this probably goes for other ontologies) zero-or-more download_infos may be attached to a version. Download_url MUST point to a STABLE file containing the ontology in the same format as specified in the download_format field Version of the ontology. no two versions of an ontology can have the same value for this field. Q: Do we want to break down the version field? For example, into major and minor version, plus tag? Submitters can attach a short name to a version. This is common practice in software releases, but not in ontologies. However, we want to offer it nontheless. Example tags might be "production", "staging", etc. Sometimes it can be useful to attach a short description or even an abstract to a release. this can be stored locally (in the string) or externally (in the URL) or both. If a URL is specified this must be a stable link to version-specific notes The status of a particular version of an ontology TBD: should probably be replaced by an enumeration The data below is per-version. The submitter will still have to provide information here when submitting the initial version. one-or-more version_infos can be attached to any one ontology. This should be filled in automatically. Only one version can be current at any one time A short and unique name for the ontology. An example would be "zebrafish_anatomy". It is strongly encouraged to keep this the same as the ontology filename (with suffix stripped). If the ontology is maintained in obo format, then this must match the obo "namespace" tag used throughout the file This is how the ontology submitter would like the ontology name to appear to people browsing OBO. It should not be too lengthy (256 chars maximum, users encouraged to use less). It can contain spaces, unicode characters, etc. It should be unique to avoid confusion. this field is optional - software should use 'concise_name' as the display label if display label is not explicitly provided The default (or only) language used in the ontology. Most, but not all, ontologies will have a dafault language. If omitted, the ontology is considered multilingual. A language that is at least partially supported in the supplied ontology. idspace_short this is a short identifier space that uniquely identifies this authority within OBO. Examples: GO, CL, MA, OBO_REL, ChEBI An additional constraint for OBO format is that all terms/classes in this ontology must use this prefix for all the IDs they control. Note that in RDF/OWL, it is the long form (see below) that is required by the RDF/OWL language specification. However, ontologies maintained in OWL MUST still provide this short form of the ID space. This is the long form of the ID space, above. It must be a valid URI. It has the exact same semantics as an XML namespace. as such it will be globally unique Ontology submitters are not required to specify this (they may not have knowledge of URIs and XML namespaces). if not specified will default to the default OBO URN which will probably be urn:lsid:bioontology.org:<IDSPACE_SHORT> for example, OBO-Cell would be urn:lsid:bioontology.org:CL This means that a CL term such as CL:0000001 would have the URI urn:lsid:bioontology.org:CL:0000001 (although CL may choose to provide a non-default idspace_uri) The combination of the idspace short name and URI A locally unique identifier that defines a language, authority, source, etc. within a given namespace. A local name and an associated description or URI that defines the name in a given context. If the URI isn't supplied, the local name is declared but not defined. The combination of a URL and an optional anchor A contact must be provided, with a valid email (which may be a mail list) should we have something to protect people from spam harvesters here? multiple contacts of different types may be listed (is this overkill?) e.g. discussion list, questions, help This type currently allows all of the types in the Dublin Core Elements or Terms class. For guidelines on creating publication references, see: Dublin Core Bibliographic Citation Guidelines these fields describe how to find out more about the ontology if blank, assumed to be available directly on homepage Each ontology is "owned" by an authority. Typically there is a 1-1 relationship between an authority and an ontology, but this is not always the case. GO consists of 3 ontologies, EVOC consists of 6 or 7. However, an ontology cannot be shared between authorities. There is always a single authority for any ontology Authority (in the sense we use it here) always corresponds to an ID space. only that authority can assign IDs in this ID space Format and version of a resource Reference to a idspace URI, name and optional version