-
Notifications
You must be signed in to change notification settings - Fork 33
Oort Tips Pipeline
This page is aimed at ontology providers
You are strongly recommended to use some kind of VCS (Version Control System).
Many ontologies are using subversion (svn). Hosting services such as google code provide a choice of VCS (including svn)
These instructions assume SVN. If you're using CVS we recommend switching to SVN. If you're using something like git, you should be advanced enough to see how to adapt these instructions.
You can use Oort to build automatic releases, e.g. daily using a system like cron or Oort Continuous Build; or you can make releases at the times of your choosing - or both.
Assume your ontology folder is set up like this:
my-ontology/
src/
ontology/
my-edit.obo # this is the file you edit
subsets/
You are strongly recommended to have an editors version of the ontology clearly indicated by a suffix such as "-edit.FMT". In general, your users should not be pointed at the edit version - they should use the derived releases. The edit version should not manually set the data-version/versionInfo tag - this is generated during release.
OBO users: Your ontology should also have the "ontology" field set (or the ontology IRI field in OWL). This should match the filename and be the lowercase form of the ID space. E.g. if your IDs are MY:nnnnn, the ontology would be "my", and the editors file would be my-edit.obo
Here is how you generate a release:
cd my-ontology/src/ontology/
ontology-release-runner --reasoner elk --simple my-edit.obo
Let's assume your ontology has two subsets - prok and euk. The derived files that will be released would look like this:
my-ontology/
src/
ontology/
my-edit.obo # this is the file you edit
my.obo # [my.owl # [2](1])
my-metadata.txt #
my-simple.obo # [my-simple.owl # [4](3])
my-simple-metadata.txt
subsets/
prok.obo
euk.obo
(If doing this for the first time, use "svn add" (or equivalent) to add these files/folders)
Note that for some ontologies, "my" and "my-simple" may be identical. It is still a good idea to release both, as your ontology may later include things that will be excluded from "my-simple". You should direct legacy applications to the simple subset and new applications to the main file.
After the files are generated, type
svn commit
(or equivalent)
You should also tag your release, somethings like this:
svn copy <REPO>/trunk/src/ontology <REPO>/releases/YYYY-MM-DD
Here REPO is the repository URL. Note the release files do not take up additional space on the subversion server.
Go to http://purl.oclc.org and register your purls:
/obo/my.obo --> <VIEWVCURL>/trunk/src/ontology/my.obo
/obo/my.owl --> <VIEWVCURL>/trunk/src/ontology/my.owl
/obo/my/subsets/ --> <VIEWVCURL>/trunk/src/ontology/subsets/
(ask obo-admin for permission)
Remember and make the directory purl a partial redirect
This is a one-time operation.
Then, for every release set up a partial redirect
/obo/my/YYYY-MM-DD --> <VIEWVCURL>/releases/YYYY-MM-DD
(TODO: figure out an easier way to do this)
First read OortMultipleOntologies
In general you should always use the obolibrary PURLs for external ontologies.
You might find it easier if you set up a Makefile for builds. For example:
OBO=http://purl.obolibrary.org/obo
release:
ontology-release-runner --reasoner elk --asserted --simple --re-mireot my-edit.obo $(OBO)/pr.owl $(OBO)/cl.owl $(OBO)/chebi.owl $(OBO)/foo.owl
then type:
make release
In general, this should be all you need to do. You will end up with:
my-ontology/
src/
ontology/
my-edit.obo # this is the file you edit
my.obo # [my.owl # [2](1])
my-metadata.txt #
my-simple.obo # [my-simple.owl # [4](3])
my-merged.obo # [my-merged.owl # [6](5])
The merged file includes the reference closure in pr, cl, chebi and foo. The main file is this same, after reasoning.
Note that the public cl file may include some pr classes in its reference closure - these are tagged with the "imported_from" IAO property - these are flushed out and recalculated, ensuring an up to date and consistent reference closure.
In some cases, you might want to do pre-processing of the external ontology. In these cases, you might want to make a subdirectory that includes a makefile for making a release of the external ontology using Oort. This adds more work to your plate, so you may want to consider simply contact the maintainers of the external ontology and requesting the subset you require as part of their standard release.
For a particularly complex example, see:
https://code.google.com/p/phenotype-ontologies/
This aggregates multiple phenotype ontologies, including dependencies on multiple external ontologies via logical definitions. See: Mungall, C. J., Gkoutos, G. V., Smith, C. L., Haendel, M. A., Lewis, S. E., and Ashburner, M. (2010). Integrating phenotype ontologies across multiple species. Genome Biology 11, R2.
See also: