Before you edit

Project notes

The following is advice for co-ordinating major edits. Ignore this section if you are only making minor changes

When working on re-structuring a whole system, it is often useful to start by making notes about the system in general, linking assertions about elements of that system to where those assertions are made in the literature.

Taking this approach, rather than going straight to a draft OBO file makes it much eaiser to write an internally consistent set of definitions to build a single coherent classification system

• Format: Use emacs org mode format
• Location: Keep the file under version control, with some informative name, in /repositories/OC_SVN/notes/Projects/
• Reference list: Maintain a reference list for the project as a flat list of minirefs at the top of the project file.

For each general type of thing to be classified:

1. List commonly used differentia (refer to list of standard properties for general type if we have one).

   • which of these can be formalised?
   • give some examples with references

2. Make a list of all subtype terms to be made under this general type

   • which already exist?

     • if poorly defined, then research further by checking existing annotations^.
     • potential merges?
     • potential clashes/difficulties with existing terms

   • for each in this list

     • what assertions can be safely made about all? - include refs and evidence summary for all
     • what assertions can only be made about some? - include refs and evidence summary for all
     • what synonyms are used - include refs.

3. List candidate classifications (genus) from among existing terms?

   • If candidate classification terms are poorly defined

^Script to search existing annotations:

Draft OBO file

Even after taking notes, it can be easier to work with a draft OBO file, rather than directly editing the ontology. This allows you to build consistent sets of terms in parallel, all with definitions built along similar lines, consistently applied classifications, relationships etc.

However, there are a number of dangers in this approach:

1. If you are going to use this later for hand editing of the ontology in emacs, you need to be scrupulous about syntax. Emacs obo-mode should help, as should the documentation of fields provided here:

http://www.geneontology.org/GO.format.obo-1_2.shtml#S.2.2

2. It is extremely imporant to avoid ID clashes.

• This can be done by assigning an unused ID space (see /repositories/OC_SVN/trunk/ID_space_log and then using an ID generator script. However, this approach should only be used for very large edits.
• In most cases it is best to simply wait until you move into using OBO-Edit before worrying about IDs. For relationships to new terms in draft OBO files, just use the names of new terms where you would normally find IDs.

When working with a draft OBO file, use the following layout as a guide (in emacs (Aquamacs) OBO mode):

`!---

[Term] id: FBbt:12345678 name: existing term ...

[Term] id: FBbt:12345678 name: new name relationship: part_of FBbt:12345679

!Notes:

!---

[Term] id: new name: fubar is_a: fu relationship: part_of FBbt:12345679

!-Notes

!---`