Neuro Behaviour Ontology (NBO)-GO alignment: Difference between revisions

From GO Wiki
Jump to navigation Jump to search
No edit summary
No edit summary
Line 6: Line 6:
#We then have three options for maintaining this alignment:
#We then have three options for maintaining this alignment:
##Provide an external file of equivalence statements between GO and NBO
##Provide an external file of equivalence statements between GO and NBO
#**advantages: Low-maintenance, wouldn't require any transfer of ids between ontologies
##*advantages: Low-maintenance, wouldn't require any transfer of ids between ontologies
#**disadvantages: Adds an extra layer of maintenance. Two ids for the same term is potentially confusing.
##*disadvantages: Adds an extra layer of maintenance. Two ids for the same term is potentially confusing.
##Include GO ids in NBO where classes are equivalent
##Include GO ids in NBO where classes are equivalent
#**advantages: Wouldn't require any non-GO ids in GO.
##*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.
##*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.
##Include NBO ids in GO where classes are equivalent
##Include NBO ids in GO where classes are equivalent
#**advantages: Clear where behaviour terms have come from. NBO remains owner of whole behaviour domain.  
##*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.
##*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 iii, 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:
#*I favour iii, 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:
#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.).
#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.).
#Maintenance: bit unsure about this. Do we do a periodic update of NBO and flag changed terms for manual checking?
#Maintenance: bit unsure about this. Do we do a periodic update of NBO and flag changed terms for manual checking?

Revision as of 12:01, 27 October 2011

  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
      • advantages: Low-maintenance, wouldn't require any transfer of ids between ontologies
      • disadvantages: Adds an extra layer of maintenance. 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 iii, 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?