- 1 Background: Relations used in GO
- 2 Migration of ontology extensions to OWL
- 3 Migration of annotation extensions relations file to OWL (proposed)
- 4 Synchronization with main RO
- 5 Note on IDs / URIs
- 6 Disjoint Documentation
- 7 Regulates Documentation
- 8 Editor Guide to has part To be reviewed
- 9 Editor Guide to Regulates To be reviewed
- 10 Look at Category:Relations
Background: Relations used in GO
The basic GO uses a small number of relations:
The full GO uses a slightly larger set:
Ontology Extension Relations
In addition, there are a number of Ontology extensions that use a wider range. This includes taxon constraint relations.
Over time, the axioms in these extensions and the relations are being merged into the main ontology.
Annotation Extension Relations
Need to look at https://github.com/geneontology/annotation_extensions/tree/master/doc Probably more recent than what is below. Also, this is what Protein2GO implements
There are also a set of relations that are used as annotation extensions (aka c16). The set overlaps with the ontology extensions set, but these are managed as separate files for now.
Relations obo file:
These come with an examples obo file that illustrates what pre-composed terms would look like with these relations
Migration of ontology extensions to OWL
Many of the ontology extensions (aka cross product files) are being moved to OWL, where they are easier to edit as separate entities. See Ontology extensions for documentation
(these will still be available as obo)
Migration of annotation extensions relations file to OWL (proposed)
- Can be edited in an ontology editor (P4) rather than by hand
- Can be edited as part of a set of imports to allow editing in P4 whilst seeing relations in context of other classes/relations
- Direct checking with reasoner
- use of imports
- thus we will import the core RO, as opposed to copy and pasting, as we do now
The primary version of the OWL file will live in GO-SVN
- ontology/extensions (not there yet)
It will be synced with the CVS repository.
OBO files will be produced automatically.
Synchronization with main RO
Currently things are a bit messy due to a number of factors, including difficulty of managing imports in oboedit as well as confusion over the state of RO. However, the situation can be rapidly improved.
Some key points:
OBO_REL is deprecated
- The core relations such as part_of have moved to the BFO upper level ontology
- The remaining relations now live in an ontology simply called "RO"
- IDs of the form OBO_REL:foo_bar indicate that this is a deprecated relation
- New relations have the ID BFO:nnnnnn or RO:nnnnn (note there is an obo format trick that allows the short form like "part_of" to be used in GO, c16, etc)
- ro_proposed is also deprecated.
Note that on http://obofoundry.org, both OBO_REL and RO are listed. OBO_REL will remain there indefinitely, but it is history as far as GO is concerned.
Note that RO still says "dev". This is because it depends on a bleeding edge version of BFO - this was unavoidable. As far as GO is concerned, RO is ready for use.
The URL is:
You are strongly recommended to view the owl version (which requires protege).
In future, different subsets will be available (like go slims).
The obo is generated from the owl, and this will be lossy.
This is currently done via laborious copy and paste and obo2owl translation.
This will be much easier moving forward editing the owl version.
The annotation relations ontology will have its primary form in OWL which curators will edit. It will import the core ro. Editors will have IDs in the GOREL range. After a while, the relations will be moved to the core RO, getting new IDs.
The import graph will look like this:
bfo ^ | ro ^ | gorel
Note on IDs / URIs
With the new RO, each relation has a standard OBO style URI and ID. E.g.
- http://purl.obolibrary.org/obo/BFO_0000050 part_of
- http://purl.obolibrary.org/obo/RO_0002202 develops_from
Obviously go.obo consumers are used to seeing "part_of" as an ID. In fact if you are to look at section 8.2 and 5.9.3 of the obo-format specification you'll see that this is in fact fine, because the go stanza reads:
[Typedef] id: occurs_in name: occurs in xref: BFO:0000066 transitive_over: part_of ! part_of
When translated to OWL, the full URI is used
Other documentation relevant to relations to be reviewed: