Automatic addition of OBO file to CVS (fwd)
Sue Rhee
rhee at acoma.Stanford.EDU
Fri Feb 13 21:24:31 EST 2004
---------- Forwarded message ----------
Date: Fri, 13 Feb 2004 16:37:25 -0800
From: Mike Cherry <cherry at genome.stanford.edu>
To: GO List <go at genome.stanford.edu>
Subject: Automatic addition of OBO file to CVS
Hello,
I have a script prepared that will automatically generate a new version
of the OBO file and commit it to the CVS. A new version of the OBO
file is only created if one of the following four files is newer than
the OBO file: GO.defs, component.ontology, function.ontology, or
process.ontology.
This script is for the period before everyone switches to writing the
OBO file. Once the switch happens no one should be committing flat
files. At that time I will start generating the flat files from the
OBO file on the server.
The idea is to continue providing the flat files for a long time, but
to have the GO Consortium switch to the OBO file in the near future.
There were no replies to my earlier message on this topic. If there is
no discussion about this I'll start committing the OBO file next week.
I was thinking of calling is it gene_ontology.obo.
Issues for discussion:
1) Obviously, we need to carefully plan when everyone switches over to
committing the OBO file. Once the editorial office is comfortable with
the new version of DAG-Edit and confident in the OBO format we need to
specify a day for the switch.
2) I can run the OBO building script every hour, although I think that
is too much. Once a day should be fine. Initially these OBO files
will be useful for testing and to allow everyone to get used to looking
at the new files.
3) Once the switch occurs everyone must switch. After the switch if a
flat file is committed any changes within that file will be lost
because I will be generating flat file parts as the OBO file changes.
The alternative would involve some type of merge between out-of-sync
flat files and the OBO file. It seems this would require humans to do
the merge. I'm open to suggestions how we could easily check for
someone doing the wrong thing.
-Mike
More information about the Po-dev
mailing list