Guidelines for creating a GO term

From GO Wiki
Jump to: navigation, search
 See Ontology_Editors_Daily_Workflow for creating branches and basic Protégé instructions.
  1. To create a new term, the Asserted view must be active (not the ‘Inferred view’).
  2. In the Class hierarchy window, click on the Add subclass button at the upper left of the window.
  3. A pop-up window will appear asking you to enter the Name of the new term. When you enter the term name, you will see your ID automatically populate the IRI box. Once you have entered the term, click ‘OK’ to save the new term. You will see it appear in the class hierarchy.
  4. Navigate to the OBO annotation window.
  5.  In the OBO annotation window add:
    1. Namespace
      1. Begin typing one of the three branches (autocomplete will guide you to the correct term): - biological_process - cellular _component - molecular_function
      2. For Type, select: xsd:string
    2. Definition
      1. Click on the + next to the Definition box
      2. Add the textual definition in the pop-up box.
      3. For Type, select: Xsd:string
      4. Click OK.
    3. Add Definition References
      1. Click on the circle with the Ref in it next to add Definition References and in the resulting pop-up click on the + to add a new ref, making sure they are properly formatted with a database abbreviation followed by a colon, followed by the text string or ID. Examples: GOC:bhm, PMID:27450630.
      2. Select Type: xsd:string
      3. Click OK.
      4. Add each definition reference separately by clicking on the + sign.
    4. Add synonyms and dbxrefs following the same procedure if they are required for the term.
  6. Create a logical definition
    1. Logical definitions are entered in the 'Equivalent to' section of the Protege Description. A a logical definition can be added by clicking on the + sign next to the Equivalent To field. A logical definition is a definition of the term using simpler statements (axioms) that taken together mean the same thing that the term means. The statements use terms either from GO or from imported ontologies linked together with relations (object properties) from the relations ontology. For example 'glucose transmembrane transport' can be defined using the equivalence axiom "transport and ('transports or maintains localization of' some glucose) and ('results in transport across' some membrane)".
    2. Note that logical definitions should be necessary and sufficient:
      1. Necessity: This means that all of the conditions that make up the logical definition must be true for the term. For example, if we used the statement "transport and ('transports or maintains localization of' glucose)" from the 'glucose transmembrane transport' above, it describes a necessary condition because in order to carry out glucose transmembrane transport, it is necessary to carry out glucose transport. If we had used "transport and ('transports or maintains localization of' D-glucose)", this would not have been necessary. It is not necessary to transport D-glucose for glucose transmembrane transport to occur. L-glucose could also be transported.
      2. Sufficiency: This means that there is nothing that fits the logical definition that does not represent the term. For example, defining a mitochondrion as "organelle and (part_of some cell)" is true, but it is not sufficient because the definitions does not specify only things that are mitochondria. There are lots of organelles that are part of a cell. In the example given above the three parts of the logical definition that describe what is being transported and that it is being transported across the membrane are sufficient to describe glucose transmembrane transport.


It is good practice to create logical definitions using the most general terms possible as the 'root' term for the definition and then to use additional clauses to make the definition necessary and sufficient. It sometimes takes some trial and error-correction to create good logical definitions. They should always be checked by running the reasoner to look at the inferred hierarchy of both superclasses and subclasses.

Some editing tips in Protege:
Quoting
Any owl entity whose label* contains a space (class, object property), must be single quoted.    Any internal single quotes should be escaped with a backslash.
Tab completion
The key to working efficiently with logical axioms is to take full advantage of the powerful autosuggest/tab-completion available in the Class Expression editor.  Just start typing, then press tab:


    1. If you have created a logical definition for your term, you can delete the asserted is_a parent in the ‘subclass of’ section. Once you re-synchronize the reasoner, you will see the automated classification of your new term. If the inferred classification doesn’t make sense, then you will need to modify the logical definition.
      • Protege tip: If you need to create a logical definition using a GO term name that does not begin with an alphabetic character, e.g. GO:0004534 (5'-3' exoribonuclease activity), navigate to the View menu in Protege and select Render by entity IRI short name (Id). This will allow you to enter a logical definition by entering the relations and term as IDs, e.g. RO_0002215 some GO_0004534. Note the use of the underscore instead of the colon in the ID. You can then return to the View menu to switch back to Render by label (rdfs:label) to see the term names.
  1. Adding other relationships: parents, disjoint statements, etc
  • If logical definitions are necessary and sufficient, the reasoner will infer almost all of the appropriate parents and children. However, in some cases it is necessary to add additional relationships because of incompleteness of the ontology.
    • Because the ontology contains different axes of differentiation and not all terms are logically defined, sometimes terms need to have manual parents added.
      • To add a manual is_a parent, click on the + symbol next to 'SubClass Of' in the description window. A new pop-up window will appear. Enter the name of the parent in the pop-up window and save. Remeber the tab-completion and quote rule mentioned above.
      • In some cases even though a logical definition is available, the reasoner will not infer all of the possible relationships a term can have. An example of this is when a term is from an external ontology that is a partonomy. In those cases, the reasoner will not infer across the partonomy. It might be necessary to assert the part_of relationships; for example, ‘heart valve development’ part_of some ‘heart development’. This is because a heart valve is part of a heart in UBERON. Therefor the development of the valve is part of the development of the heart. When external ontologies are used in axioms, it is important to browse the external ontologies to be sure that relationships aren't missing.
      • Defining disjoint classes is difficult but very important. Disjoint classes are classes that contain no overlap of individuals. It is often difficult to decide if two biological classes are disjoint, but if the determination can be made the disjoint classes should be declared using the 'Disjoint With' field in the Description window.
  1. When you have finished adding the term, you can hover over it in the class window to reveal its GO_id.
  2. Save the file and return to your terminal window. Then, type: git status. This will confirm which file has been modified.
  3. To see how the branch was modified, type: git diff. In this case, go-edit.obo was modified. The text below is not the entire diff for this edit, but is an example. If the diff is very large, you will need to hit space to continue to see it and then hit q to get back to the prompt at the end of the diff file.
   ~/repos/go-ontology/src/ontology(issue-13390) $ git diff
   diff --git a/src/ontology/go-edit.obo b/src/ontology/go-edit.obo
   index 72ae7e9..8d47fa1 100644
   --- a/src/ontology/go-edit.obo
   +++ b/src/ontology/go-edit.obo
   @@ -400751,6 +400751,85 @@ created_by: dph
    creation_date: 2017-04-28T12:39:13Z
    
    [Term]
   +id: GO:0061868
   +name: hepatic stellate cell migration
   +namespace: biological_process
   +def: "The orderly movement of a hepatic stellate cell from one site to another." [PMID:24204762]
   +intersection_of: GO:0016477 ! cell migration
   +intersection_of: results_in_movement_of CL:0000632 ! hepatic stellate cell
   +created_by: dph
   +creation_date: 2017-05-01T13:01:40Z
   +
   +[Term]
    id: GO:0065001
    name: specification of axis polarity
    namespace: biological_process
   ~/repos/go-ontology/src/ontology(issue-13390) $
 See Ontology_Editors_Daily_Workflow for commit, push and merge instructions.

Review Status

Last reviewed: Jan 8, 2019

Back to: Ontology Editing Guide