Neuro Behaviour Ontology (NBO)-GO alignment

From GO Wiki
Jump to navigation Jump to search
  1. Check existing alignment:
    • Generate a report of mismatches between GO and NBO. George has a file of equivalence statements that apparently covers all GO behaviour terms (http://code.google.com/p/behavior-ontology/source/browse/trunk/behavior_xp.obo) so this should be fairly straightforward.
    • Fix errors and omissions in GO (and NBO) so that the ontologies align.
    • Check for behaviour terms in GO missing from NBO (probably manual).
  2. Survey users about implications of using e.g. non-GO ids in GO.
  3. We then have three options for maintaining this alignment:
    1. Provide an external file of equivalence statements between GO and NBO, or for one of the ontologies to maintain xrefs to the other, and add a "treat-xrefs-as-equivalent" header to the file
      • advantages: Low-maintenance, wouldn't require any transfer of ids between ontologies
      • disadvantages: Adds an extra layer of maintenance (although the latter option allow the mapping to be automatically generated by Oort release system). Two ids for the same term is potentially confusing.
    2. Include GO ids in NBO where classes are equivalent
      • advantages: Wouldn't require any non-GO ids in GO.
      • disadvantages: NBO wouldn't own the domain of behaviour - they would need to make judgements about what bits belonged to GO and which to them.
    3. Include NBO ids in GO where classes are equivalent
      • advantages: Clear where behaviour terms have come from. NBO remains owner of whole behaviour domain.
      • disadvantages: Requires software to handle non-GO ids within GO. We wouldn't be able to filter these ids out from downstream files without losing terms. Changing ids for these files is inadvisable.
    • I favour 3, because this seems the cleanest and most transparent to users. There are potentially issues with software handling NBO ids in GO though, which need looking in to. Given that these issues can be surmounted, the next steps would be:
  4. Replace GO ids with equivalent NBO ids and definitions. Retain relationships from NBO and GO (probably need some QC here to check for redundancy etc.).
  5. Maintenance: bit unsure about this. Do we do a periodic update of NBO and flag changed terms for manual checking?